[PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[Denis Efremov]

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@compro.net/
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;
-- 
2.31.1

Re: [PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[Jiri Kosina]

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

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[Denis Efremov]

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.
> 
> [1] https://bugzilla.suse.com/show_bug.cgi?id=1181018

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/dc30fd4383e57a0440cdb0e16ba5c4336a43b290

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

Re: [PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[Thorsten Leemhuis]

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@compro.net/

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

Re: [PATCH] Revert "floppy: reintroduce O_NDELAY fix"

[Thorsten Leemhuis]

On 30.08.21 11:20, Thorsten Leemhuis wrote:
> 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@compro.net/
> 
> 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/

TWIMC: the above made me find and fix a few bugs and other problems in
regzbot. But regzbot didn't automatically close the record when the
revert was merged, which was my fault, as above commands didn't point to
the initial report (the one referenced in the revert). So I'm adding it
now with below line (with only regressions list in To: to avoid spamming
people) to make regzbot handle such situations retroactively:

#regzbot monitor
https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@compro.net/