The patch breaks userspace implementations (e.g. fdutils) and introduces regressions in behaviour. Previously, it was possible to O_NDELAY open a floppy device with no media inserted or with write protected media without an error. Some userspace tools use this particular behavior for probing.
It's not the first time when we revert this patch. Previous revert is in commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@com... Reported-by: Mark Hounschell markh@compro.net Cc: Jiri Kosina jkosina@suse.cz Cc: Wim Osterholt wim@djo.tudelft.nl Cc: Kurt Garloff kurt@garloff.de Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov efremov@linux.com --- drivers/block/floppy.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 87460e0e5c72..fef79ea52e3e 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -4029,23 +4029,23 @@ static int floppy_open(struct block_device *bdev, fmode_t mode) if (fdc_state[FDC(drive)].rawcmd == 1) fdc_state[FDC(drive)].rawcmd = 2;
- if (mode & (FMODE_READ|FMODE_WRITE)) { - drive_state[drive].last_checked = 0; - clear_bit(FD_OPEN_SHOULD_FAIL_BIT, &drive_state[drive].flags); - if (bdev_check_media_change(bdev)) - floppy_revalidate(bdev->bd_disk); - if (test_bit(FD_DISK_CHANGED_BIT, &drive_state[drive].flags)) - goto out; - if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &drive_state[drive].flags)) + if (!(mode & FMODE_NDELAY)) { + if (mode & (FMODE_READ|FMODE_WRITE)) { + drive_state[drive].last_checked = 0; + clear_bit(FD_OPEN_SHOULD_FAIL_BIT, + &drive_state[drive].flags); + if (bdev_check_media_change(bdev)) + floppy_revalidate(bdev->bd_disk); + if (test_bit(FD_DISK_CHANGED_BIT, &drive_state[drive].flags)) + goto out; + if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &drive_state[drive].flags)) + goto out; + } + res = -EROFS; + if ((mode & FMODE_WRITE) && + !test_bit(FD_DISK_WRITABLE_BIT, &drive_state[drive].flags)) goto out; } - - res = -EROFS; - - if ((mode & FMODE_WRITE) && - !test_bit(FD_DISK_WRITABLE_BIT, &drive_state[drive].flags)) - goto out; - mutex_unlock(&open_lock); mutex_unlock(&floppy_mutex); return 0;
On Sun, 8 Aug 2021, Denis Efremov wrote:
The patch breaks userspace implementations (e.g. fdutils) and introduces regressions in behaviour. Previously, it was possible to O_NDELAY open a floppy device with no media inserted or with write protected media without an error. Some userspace tools use this particular behavior for probing.
It's not the first time when we revert this patch. Previous revert is in commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
By reverting it you bring back the bugs that were fixed by it -- e.g. the possibility to livelock mmap() on the returned fd to keep waiting on the page unlock bit forever, or the functionality bug reported at [1], and likely others.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1181018
Hi,
On 8/16/21 10:17 AM, Jiri Kosina wrote:
On Sun, 8 Aug 2021, Denis Efremov wrote:
The patch breaks userspace implementations (e.g. fdutils) and introduces regressions in behaviour. Previously, it was possible to O_NDELAY open a floppy device with no media inserted or with write protected media without an error. Some userspace tools use this particular behavior for probing.
It's not the first time when we revert this patch. Previous revert is in commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
By reverting it you bring back the bugs that were fixed by it
I agree with you, that O_NDELAY is broken for floppies (and always been). However, just by removing O_NDELAY we break many existing tools that use it for probing and ioctl-only opens. With the patch tools fail to open the device without a diskette and try to read a diskette if there is one (this is not as fast on a real hardware as in QEMU). I think that there should be a better fix that doesn't break existing tools. It appears that people still use software that depends on O_NDELAY in floppies. Same patch was already reverted in 2016 (presumably) by the same reason.
-- e.g. the possibility to livelock mmap() on the returned fd to keep waiting on the page unlock bit forever
As far as I understand this is a problem only for syzkaller. And this is not a security issue nowadays since most distributions (I don't know exceptions) require at least "disk" group to access floppies. Do you know a link for the syzkaller reproducer?
or the functionality bug reported at [1], and likely others.
The patch starts to return -ENXIO for O_NDELAY|O_RDONLY opens and devices without a diskette. I don't think this is an expected behavior during libblkid probing.
Probably there is a better fix for [1], maybe even an additional workaround for floppies in libblkid. They already have workarounds for cdroms https://github.com/karelzak/util-linux/commit/dc30fd4383e57a0440cdb0e16ba5c4...
I started to add simple tests https://lkml.org/lkml/2021/8/18/845 However, I failed to reproduce mount bug [1], probably because I don't know how to configure cloudinit properly. I tried to reproduce a mount fail bug with open("/dev/fd0", O_NDELAY|O_RDONLY) and mount("/dev/fd0", ...) but it works. Looks like there should be something else in between...
Regards, Denis
On 08.08.21 09:42, Denis Efremov wrote:
The patch breaks userspace implementations (e.g. fdutils) and introduces regressions in behaviour. Previously, it was possible to O_NDELAY open a floppy device with no media inserted or with write protected media without an error. Some userspace tools use this particular behavior for probing.
It's not the first time when we revert this patch. Previous revert is in commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@com...
FYI, I'm just starting to act as regression tracker again and will add this to the list of tracked regressions.
Feel free to ignore the rest of this message, it's intended for the regression tracking bot I'm writing. This "regzbot" in fact is running now and this is the first regression that gets added to the database (I'm sure despite a lot of testing something will go wrong, but don't worry about it, I'll deal with it on my side). See also: https://linux-regtracking.leemhuis.info/post/inital-regzbot-running/ https://linux-regtracking.leemhuis.info/post/regzbot-approach/
#regzbot ^introduced 8a0c014cd20516ade9654fc13b51345ec58e7be8 #regzbot monitor https://lore.kernel.org/lkml/20210818154646.925351-1-efremov@linux.com/ #regzbot monitor https://lore.kernel.org/lkml/388418f4-2b9a-6fed-836c-a004369dc7c0@linux.com/
Ciao, Thorsten
linux-stable-mirror@lists.linaro.org
-
Denis Efremov -
Jiri Kosina -
Thorsten Leemhuis