Bug 1548938

Summary:	scsi: the read-only attribute of SCSI disk just works only once.
Product:	[Fedora] Fedora	Reporter:	lining57 <lining57>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	28	CC:	airlied, ajax, bskeggs, dengguoqiang, ewk, hdegoede, ichavero, itamar, jarodwilson, jcline, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, lining57, linville, mchehab, mjg59, steved
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	kernel-4.16.0-0.rc6.git0.2.fc28	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-30 13:10:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description lining57 2018-02-26 04:29:17 UTC

Description of problem:

Hi, 

We found a problem when using SCSI device.
The read-only attribute of SCSI disk just works only once. 

Setting the read-only attribute to SCSI disk by calling “ioctl(fd, BLKROSET, &ro”), 
and dd to the SCSI disk many times, only the first write operation was denied.

Version-Release number of selected component (if applicable):
systemd  version >213

How reproducible:
100%

Steps to Reproduce:

keep the SCSI disk unmount.
1. blockdev --setro /dev/sdc
2. dd if=/dev/zero of=/dev/sdc count=1024
3. dd if=/dev/zero of=/dev/sdc count=1024


Actual results:

set read-only on SCSI disk by "blockdev --setro /dev/sdc", and dd many times, dd operation is denied just for the first time.

Expected results:

set read-only on SCSI disk by "blockdev --setro /dev/sdc" and dd many times, dd operation is alwayes denied

Additional info:

Here is a test result:

[root@localhost ~]# blockdev --setro /dev/sdc
[root@localhost ~]# dd if=/dev/zero of=/dev/sdc count=1024 bs=1
dd: error writing ‘/dev/sdc’: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000293249 s, 0.0 kB/s
[root@localhost ~]# dd if=/dev/zero of=/dev/sdc count=1024 bs=1
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00469032 s, 218 kB/s
[root@localhost ~]# dd if=/dev/zero of=/dev/sdc count=1024 bs=1
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00542073 s, 189 kB/s

Comment 1 lining57 2018-02-26 04:48:00 UTC

Environment:
  - Kernel: ALL
  We reproduced this problem in following kernel version: 4.15 4.10, 3.10.
  And by reference source, we think the problem exist in all versions.
  
  - Driver: SCSI
  it exists only when using SCSI disks, and xen-blk，virtio-blk do not have such a 
  problem

  - Software: Systemd
  it exsits just in the systemd version > v213

Comment 2 lining57 2018-02-26 04:48:15 UTC

Environment:
  - Kernel: ALL
  We reproduced this problem in following kernel version: 4.15 4.10, 3.10.
  And by reference source, we think the problem exist in all versions.
  
  - Driver: SCSI
  it exists only when using SCSI disks, and xen-blk，virtio-blk do not have such a 
  problem

  - Software: Systemd
  it exsits just in the systemd version > v213

Comment 3 Laura Abbott 2018-02-27 01:34:38 UTC

I'm a bit confused by the mention of systemd, does the problem exist if you use an older system?

Comment 4 lining57 2018-02-27 02:35:50 UTC

(In reply to Laura Abbott from comment #3)
> I'm a bit confused by the mention of systemd, does the problem exist if you
> use an older system?

Hi, Thanks for replying.

This problem does't exsit in an older system ( whose systemd <= v213) .
It can be reproduced easily in newer system.

I have done some investigation about this problem. 
Here is what I found:

This problem is related to systemd-udevd and kernel SCSI driver.

When dd to a disk or use syscall "write()" to write raw disk  directly, 
systemd-udevd will  re-read  the partition table of the disk by calling 
"ioctl(fd,BLKRRPART)".  And The SCSI driver set the ro=1 back to ro=0. 
The action of SCSI driver is strange .

 It exists only when using SCSI driver, and xen-blk，virtio-blk do not have such a problem.

After reading the source code of systemd , I found that systemd-udevd uses"inotify" to listen the block device events，when a block device opened for writing being closed，the systemd-udevd will receive the event. It will re-read the partition table.

It seems to be a kernel bug , re-reading the partition table should not have an effect on the read-only flag of block devices.

I set a dump_stack() in set_disk_ro to print how  the ro changed back to rw unexpectedly.

[  145.269021] CPU: 3 PID: 544 Comm: systemd-udevd Tainted: G           O   ----V-------   3.10.0 #2
[  145.269026] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[  145.269028]  0000000000000000 00000000e843e1df ffff880035943cb0 ffffffff81641fcf
[  145.269032]  ffff880035943d10 ffffffff812e0eb9 00000000e843e1df ffff88003541a800
[  145.269034]  00000000000000b1 ffff880035943d10 ffffffff814218f5 ffff88003541a800
[  145.269040] Call Trace:
[  145.269094]  [<ffffffff81641fcf>] dump_stack+0x19/0x1b
[  145.269114]  [<ffffffff812e0eb9>] set_disk_ro+0x29/0x100
[  145.269127]  [<ffffffff814218f5>] ? scsi_get_vpd_page+0x35/0xd0
[  145.269216]  [<ffffffffa01e6a58>] sd_revalidate_disk+0x468/0xde0 [sd_mod]
[  145.269220]  [<ffffffff812e42f2>] rescan_partitions+0x92/0x2c0
[  145.269223]  [<ffffffff812df2b9>] __blkdev_reread_part+0x69/0x70
[  145.269225]  [<ffffffff812df2e3>] blkdev_reread_part+0x23/0x40
[  145.269228]  [<ffffffff812df81e>] blkdev_ioctl+0x7e/0x760
[  145.269239]  [<ffffffff8121e8b1>] block_ioctl+0x41/0x50
[  145.269249]  [<ffffffff811f6a25>] do_vfs_ioctl+0x2e5/0x4c0
[  145.269263]  [<ffffffff8129261e>] ? file_has_perm+0xae/0xc0
[  145.269287]  [<ffffffff8123539b>] ? locks_alloc_lock+0x1b/0x60
[  145.269290]  [<ffffffff811f6ca1>] SyS_ioctl+0xa1/0xc0
[  145.269298]  [<ffffffff81652449>] system_call_fastpath+0x16/0x1b


I have also submitted a issues to systemd.
https://github.com/systemd/systemd/issues/8141

Comment 5 Jeremy Cline 2018-03-02 14:43:14 UTC

Hi,

I submitted a patch upstream that fixes this (https://marc.info/?l=linux-kernel&m=151991329622936) which was accepted for by the SCSI maintainers for 4.16.

Comment 6 lining57 2018-03-03 08:13:27 UTC

(In reply to Jeremy Cline from comment #5)
> Hi,
> 
> I submitted a patch upstream that fixes this
> (https://marc.info/?l=linux-kernel&m=151991329622936) which was accepted for
> by the SCSI maintainers for 4.16.

Hi, Thanks for fixing this problem.

So it will be fix in 4.16 ?    : )  
Could you paste a commit id here when this patch beening merged info master. 

Thanks.

Comment 7 Jeremy Cline 2018-03-15 17:00:23 UTC

The fix is now in Linus's tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20bd1d026aacc5399464f8328f305985c493cde3.

Comment 8 Sandy 2018-03-16 07:35:28 UTC

(In reply to Jeremy Cline from comment #7)
> The fix is now in Linus's tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=20bd1d026aacc5399464f8328f305985c493cde3.

Thanks very much. ：）

Comment 9 Fedora Update System 2018-03-20 15:54:13 UTC

kernel-4.16.0-0.rc6.git0.2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5ffc6f479f

Comment 10 Fedora Update System 2018-03-21 14:13:21 UTC

kernel-4.16.0-0.rc6.git0.2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5ffc6f479f

Comment 11 Fedora Update System 2018-03-30 13:10:52 UTC

kernel-4.16.0-0.rc6.git0.2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.