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
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
I'm a bit confused by the mention of systemd, does the problem exist if you use an older system?
(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
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.
(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.
The fix is now in Linus's tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20bd1d026aacc5399464f8328f305985c493cde3.
(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. ：）
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
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
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.