Resend: Another 4.4 to 4.5 floppy issue
Subsystems (2)
Just rejoined the list due to floppy open problems created from 4.4 to 4.5. I found the following email that indicates a fix for one of the problems.
From: Jiri Kosina <[email protected]>
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that this is being used setfdprm userspace for ioctl-only open().
Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original O_NDELAY bug fixed.
---
Jens, this should preferably go into 4.7-rcX and to -stable as well.
drivers/block/floppy.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)
drivers/block/floppy.c +9 -12
@@ -3663,11 +3663,6 @@ static int floppy_open(struct block_device *bdev, fmode_t mode) opened_bdev[drive] = bdev; -if (!(mode & (FMODE_READ |FMODE_WRITE ))) { - res = -EINVAL ; - goto out; - } - res = -ENXIO ;if (!floppy_track_buffer) {
@@ -3711,13 +3706,15 @@ static int floppy_open(struct block_device *bdev, fmode_t mode)if (UFDCS ->rawcmd ==1 )UFDCS ->rawcmd =2 ; -UDRS ->last_checked =0 ; -clear_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags); -check_disk_change (bdev); -if (test_bit (FD_DISK_CHANGED_BIT , &UDRS ->flags)) - goto out; -if (test_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags)) - goto out; +if (mode & (FMODE_READ |FMODE_WRITE )) { +UDRS ->last_checked =0 ; +clear_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags); +check_disk_change (bdev); +if (test_bit (FD_DISK_CHANGED_BIT , &UDRS ->flags)) + goto out; +if (test_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags)) + goto out; + } res = -EROFS ;
Signature · 15 lines
Jiri Kosina SUSE Labs But this does not completely fix all the problems induced by the original changes from 4.4 to 4.5. The following is what we use to open the floppy. fd = open(device, O_RDWR | O_NDELAY); The FMODE_NDELAY check that was removed now prevents one from doing an open of the device with no media inserted. It also prevents one from doing an open of the device with media inserted that is not already formatted in a "standard" format. I do both of these things a lot. I deal with a few very non-standard formats and this change prevents me from doing what I've been doing for YEARS. Could we please get the original behavior back in the floppy driver. Thanks and regards Mark
Quoted 14 lines · Mark Hounschell
From: Jiri Kosina <[email protected]>
Commit
09954bad4("floppy: refactoropen()flags handling"), as a side-effect, causesopen(/dev/fdX, O_ACCMODE)to fail. It turns out that this is being used setfdprm userspace for ioctl-onlyopen().Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original
O_NDELAYbug fixed.Cc [email protected] # v4.5+Reported-by Wim Osterholt <[email protected]>Tested-by Wim Osterholt <[email protected]>Signed-off-by Jiri Kosina <[email protected]>---
[ ... snip ... ]
Quoted 4 lines
But this does not completely fix all the problems induced by the original changes from 4.4 to 4.5. The following is what we use to open the floppy.
Quoted 8 lines
fd =
open(device, O_RDWR | O_NDELAY);The
FMODE_NDELAYcheck that was removed now prevents one from doing an open of the device with no media inserted. It also prevents one from doing an open of the device with media inserted that is not already formatted in a "standard" format. I do both of these things a lot. I deal with a few very non-standard formats and this change prevents me from doing what I've been doing for YEARS. Could we please get the original behavior back in the floppy driver.
Hi Mark,
thanks for the regression report.
For my better understanding of your issue -- what behavior/semantics exactly does your userspace think it'll be getting from opening /dev/fd0 with O_NDELAY?
Thanks,
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 32 lines · Jiri Kosina
Quoted 14 lines · Mark Hounschell
From: Jiri Kosina <[email protected]>
Commit
09954bad4("floppy: refactoropen()flags handling"), as a side-effect, causesopen(/dev/fdX, O_ACCMODE)to fail. It turns out that this is being used setfdprm userspace for ioctl-onlyopen().Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original
O_NDELAYbug fixed.Cc [email protected] # v4.5+Reported-by Wim Osterholt <[email protected]>Tested-by Wim Osterholt <[email protected]>Signed-off-by Jiri Kosina <[email protected]>---
[ ... snip ... ]
Quoted 4 lines
But this does not completely fix all the problems induced by the original changes from 4.4 to 4.5. The following is what we use to open the floppy.
Quoted 8 lines
fd =
open(device, O_RDWR | O_NDELAY);The
FMODE_NDELAYcheck that was removed now prevents one from doing an open of the device with no media inserted. It also prevents one from doing an open of the device with media inserted that is not already formatted in a "standard" format. I do both of these things a lot. I deal with a few very non-standard formats and this change prevents me from doing what I've been doing for YEARS. Could we please get the original behavior back in the floppy driver.Hi Mark,
Quoted 8 lines
thanks for the regression report.
For my better understanding of your issue -- what behavior/semantics exactly does your userspace think it'll be getting from opening
/dev/fd0withO_NDELAY?Thanks,
Hi Jiri.
Well, all that was specified in my original post. I can no longer open the floppy drive with no floppy media inserted. Worse, I can also no longer open a floppy with media inserted that is not a "linux" recognized format. A floppy drive is a removable media device and should be treated as such. The original implementation of the O_NDELAY flag allowed it to be.
Any removable media device should be capable of being opened with no, or even unrecognizable media installed. The kernel and its utilities should not "assume" to much when it comes to removable media. Consider a SCSI tape drive or even a removable media SCSI disk drive. How would you explain an open failure to someone trying to open a SCSI tape drive that had no tape or even a "non-tar" formatted tape media in it??? Or better yet, trying to open a removable media device the was write protected but didn't include O_RDONLY in the open?
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now so I am really confused as to why these changes were induced.
As for the "O_RDONLY | O_WRONLY" thing you decided to change back, which I'm happy to see, was wrong. Almost ALL removable media devices have W/R protection built into the media. For ever, I understood that it was MY responsibility to write protect my removable media. An open of a removable device should never even care about that stuff. It is the users responsibility.
We use extensively, the FDRAWCMD ioctl API. It is totally borked now for us without maintaining our own kernel patch that reverts the changes from 4.4 to 4.5.
Regards
Mark
Quoted 6 lines · Mark Hounschell
Well, all that was specified in my original post. I can no longer open the floppy drive with no floppy media inserted. Worse, I can also no longer open a floppy with media inserted that is not a "linux" recognized format. A floppy drive is a removable media device and should be treated as such. The original implementation of the
O_NDELAYflag allowed it to be.
Quoted 8 lines
Any removable media device should be capable of being opened with no, or even unrecognizable media installed. The kernel and its utilities should not "assume" to much when it comes to removable media. Consider a SCSI tape drive or even a removable media SCSI disk drive. How would you explain an open failure to someone trying to open a SCSI tape drive that had no tape or even a "non-tar" formatted tape media in it???
Or better yet, trying to open a removable media device the was write protected but didn't includeO_RDONLYin the open?
Alright, so you are basically supplementing O_NDELAY flag in order to avoid check_disk_change() being called. It's rather a coincidence that it has worked this way, but I agree with you that we can't ignore the fact that there is userspace relying on this behavior.
Quoted 4 lines
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now
That's not really true; the code is a racy mess, and this is being uncovered only when virtualized floppy devices started to exist (because they are much faster than a real hardware, and the different timing reveals bugs that were not visible before).
This particular fix was because syzkaller found a way how easily corrupt kernel memory using O_NDELAY to floppy driver; see
https://lkml.org/lkml/2016/2/2/848
Quoted 1 line
so I am really confused as to why these changes were induced.
The floppy driver is in an orphan mode; no new "features" are added "just because". Everything that's happening there is to fix real bugs in the kernel.
I'll look into ways how to fix this, but I am afraid this is going to be really tricky. Therefore we'd have to very likely proceed asap with revert of 09954bad448 and coming up with a workaround that'd still avoid the bug reported by syzkaller.
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 17 lines · Jiri Kosina
Quoted 6 lines · Mark Hounschell
Well, all that was specified in my original post. I can no longer open the floppy drive with no floppy media inserted. Worse, I can also no longer open a floppy with media inserted that is not a "linux" recognized format. A floppy drive is a removable media device and should be treated as such. The original implementation of the
O_NDELAYflag allowed it to be.Quoted 8 lines
Any removable media device should be capable of being opened with no, or even unrecognizable media installed. The kernel and its utilities should not "assume" to much when it comes to removable media. Consider a SCSI tape drive or even a removable media SCSI disk drive. How would you explain an open failure to someone trying to open a SCSI tape drive that had no tape or even a "non-tar" formatted tape media in it???
Or better yet, trying to open a removable media device the was write protected but didn't includeO_RDONLYin the open?
Quoted 5 lines
Alright, so you are basically supplementing
O_NDELAYflag in order to avoidcheck_disk_change()being called. It's rather a coincidence that it has worked this way, but I agree with you that we can't ignore the fact that there is userspace relying on this behavior.
I'm not supplementing anything. The driver _did_ this on its own. I just expect to be able to open the drive to get a handle without the kernel attempting to access the media. My apps manage a disk_change on their own. I don't think its check_disk_change that gives me my pain. There is some probe happening that fails when a floppy is installed that is not a "standard" format. That causes the open to fail which is the most pain. Still I should be able to get a handle without any media or even unrecognized media installed.
Funny, though even fdformat from the linux-utils package won't allow me to format a floppy that is NOT already formatted in a supported format. Once I format a floppy to an other than standard format, fdformat will not allow me to reformat it back to a standard format. Doesn't make much sense does it? "Unable to format a floppy that is not already formatted??" That is another issue though.
Quoted 10 lines
Quoted 4 lines
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now
That's not really true; the code is a racy mess, and this is being uncovered only when virtualized floppy devices started to exist (because they are much faster than a real hardware, and the different timing reveals bugs that were not visible before).
Forgive me here as I'm ignorant about why any virtualized floppy would require the real physical kernel floppy driver to be involved at all. We also do virtualized floppies in our user land apps but we certainly don't require any kernel floppy driver support to do it?
Quoted 7 lines
This particular fix was because syzkaller found a way how easily corrupt kernel memory using
O_NDELAYto floppy driver; seehttps://lkml.org/lkml/2016/2/2/848Quoted 1 line
so I am really confused as to why these changes were induced.
Quoted 9 lines
The floppy driver is in an orphan mode; no new "features" are added "just because". Everything that's happening there is to fix real bugs in the kernel.
I'll look into ways how to fix this, but I am afraid this is going to be really tricky. Therefore we'd have to very likely proceed asap with revert of
09954bad448and coming up with a workaround that'd still avoid the bug reported by syzkaller.
I would be happy to do some testing for you if needed. At least with regard to our apps.
Regards
Mark
Quoted 6 lines · Mark Hounschell
Quoted 4 lines
Alright, so you are basically supplementing
O_NDELAYflag in order to avoidcheck_disk_change()being called. It's rather a coincidence that it has worked this way, but I agree with you that we can't ignore the fact that there is userspace relying on this behavior.I'm not supplementing anything. The driver _did_ this on its own.
I mean, you're passing O_NDELAY to open(/dev/fd0) exactly to avoid kernel issuing check_disk_change(). That's the only semantics O_NDELAY has for fd.
Quoted 7 lines
I just expect to be able to open the drive to get a handle without the kernel attempting to access the media. My apps manage a
disk_changeon their own. I don't think itscheck_disk_changethat gives me my pain. There is some probe happening that fails when a floppy is installed that is not a "standard" format. That causes the open to fail which is the most pain. Still I should be able to get a handle without any media or even unrecognized media installed.
Yeah, that's check_disk_change().
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now
Quoted 7 lines
Quoted 4 lines
That's not really true; the code is a racy mess, and this is being uncovered only when virtualized floppy devices started to exist (because they are much faster than a real hardware, and the different timing reveals bugs that were not visible before).
Forgive me here as I'm ignorant about why any virtualized floppy would require the real physical kernel floppy driver to be involved at all.
Because VMs (such as qemu) actually do emulate a FDC on a hardware level, but don't emulate the timings of the real hardware (which are not mandated by the spec, but "are just there").
Quoted 11 lines
Quoted 11 lines
This particular fix was because syzkaller found a way how easily corrupt kernel memory using
O_NDELAYto floppy driver; seehttps://lkml.org/lkml/2016/2/2/848Quoted 1 line
so I am really confused as to why these changes were induced.
The floppy driver is in an orphan mode; no new "features" are added "just because". Everything that's happening there is to fix real bugs in the kernel.
Quoted 7 lines
Quoted 4 lines
I'll look into ways how to fix this, but I am afraid this is going to be really tricky. Therefore we'd have to very likely proceed asap with revert of
09954bad448and coming up with a workaround that'd still avoid the bug reported by syzkaller.I would be happy to do some testing for you if needed. At least with regard to our apps.
Could you please check whether my last patch that Jens queued in linux-block.git ("floppy: fix open(O_ACCMODE) for ioctl-only open" in for-linus branch) remedies at least some of the issues you are seeing?
Thanks,
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 57 lines · Jiri Kosina
Quoted 6 lines · Mark Hounschell
Quoted 4 lines
Alright, so you are basically supplementing
O_NDELAYflag in order to avoidcheck_disk_change()being called. It's rather a coincidence that it has worked this way, but I agree with you that we can't ignore the fact that there is userspace relying on this behavior.I'm not supplementing anything. The driver _did_ this on its own.
I mean, you're passing
O_NDELAYto open(/dev/fd0) exactly to avoid kernel issuingcheck_disk_change(). That's the only semanticsO_NDELAYhas for fd.Quoted 7 lines
I just expect to be able to open the drive to get a handle without the kernel attempting to access the media. My apps manage a
disk_changeon their own. I don't think itscheck_disk_changethat gives me my pain. There is some probe happening that fails when a floppy is installed that is not a "standard" format. That causes the open to fail which is the most pain. Still I should be able to get a handle without any media or even unrecognized media installed.Yeah, that's
check_disk_change().Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now
Quoted 7 lines
Quoted 4 lines
That's not really true; the code is a racy mess, and this is being uncovered only when virtualized floppy devices started to exist (because they are much faster than a real hardware, and the different timing reveals bugs that were not visible before).
Forgive me here as I'm ignorant about why any virtualized floppy would require the real physical kernel floppy driver to be involved at all.
Because VMs (such as qemu) actually do emulate a FDC on a hardware level, but don't emulate the timings of the real hardware (which are not mandated by the spec, but "are just there").
Quoted 16 lines
Quoted 15 lines
This particular fix was because syzkaller found a way how easily corrupt kernel memory using
O_NDELAYto floppy driver; seehttps://lkml.org/lkml/2016/2/2/848Quoted 1 line
so I am really confused as to why these changes were induced.
The floppy driver is in an orphan mode; no new "features" are added "just because". Everything that's happening there is to fix real bugs in the kernel.
I'll look into ways how to fix this, but I am afraid this is going to be really tricky. Therefore we'd have to very likely proceed asap with revert of
09954bad448and coming up with a workaround that'd still avoid the bug reported by syzkaller.
Quoted 7 lines
Quoted 2 lines
I would be happy to do some testing for you if needed. At least with regard to our apps.
Could you please check whether my last patch that Jens queued in linux-block.git ("floppy: fix
open(O_ACCMODE)for ioctl-only open" in for-linus branch) remedies at least some of the issues you are seeing?
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git. A patch for 4.5 would be easy for me though.
Mark
Quoted 1 line · Mark Hounschell
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
Quoted 1 line
A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (ff06db1ef). Testing it in your environment would be appreciated.
Thanks,
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 4 lines · Jiri Kosina
Quoted 1 line · Mark Hounschell
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
Quoted 9 lines
It's there.
Quoted 1 line
A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (
ff06db1ef). Testing it in your environment would be appreciated.Thanks,
I just tested what is currently in Linus' tree and it does NOT work for me.
Mark
Quoted 2 lines · Mark Hounschell
I just tested what is currently in Linus' tree and it does NOT work for me.
Is there some minimalized reproducer you are seeing the regression with that you could share?
Thanks,
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 10 lines · Jiri Kosina
Quoted 2 lines · Mark Hounschell
I just tested what is currently in Linus' tree and it does NOT work for me.
Is there some minimalized reproducer you are seeing the regression with that you could share?
Thanks,
Your patch is NOT there yet. There is no reference to NODELAY in the floppy driver of Linus tree that I checked out yesterday.
Mark
Quoted 6 lines · Mark Hounschell
Quoted 4 lines
Is there some minimalized reproducer you are seeing the regression with that you could share?
Thanks,
Your patch is NOT there yet.
We're talking about ff06db1ef.
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 39 lines · Jiri Kosina
Quoted 6 lines · Mark Hounschell
Well, all that was specified in my original post. I can no longer open the floppy drive with no floppy media inserted. Worse, I can also no longer open a floppy with media inserted that is not a "linux" recognized format. A floppy drive is a removable media device and should be treated as such. The original implementation of the
O_NDELAYflag allowed it to be.Quoted 8 lines
Any removable media device should be capable of being opened with no, or even unrecognizable media installed. The kernel and its utilities should not "assume" to much when it comes to removable media. Consider a SCSI tape drive or even a removable media SCSI disk drive. How would you explain an open failure to someone trying to open a SCSI tape drive that had no tape or even a "non-tar" formatted tape media in it???
Or better yet, trying to open a removable media device the was write protected but didn't includeO_RDONLYin the open?Alright, so you are basically supplementing
O_NDELAYflag in order to avoidcheck_disk_change()being called. It's rather a coincidence that it has worked this way, but I agree with you that we can't ignore the fact that there is userspace relying on this behavior.Quoted 4 lines
The original behavior of the floppy driver was correct. I have no idea what BUG these changes were supposed to fix but the "fix" obviously broke user land. Was this bug reported by some new ROBOT test or something? The kernel floppy driver has been stable for years now
That's not really true; the code is a racy mess, and this is being uncovered only when virtualized floppy devices started to exist (because they are much faster than a real hardware, and the different timing reveals bugs that were not visible before).
This particular fix was because syzkaller found a way how easily corrupt kernel memory using
O_NDELAYto floppy driver; seehttps://lkml.org/lkml/2016/2/2/848Quoted 1 line
so I am really confused as to why these changes were induced.
Quoted 9 lines
The floppy driver is in an orphan mode; no new "features" are added "just because". Everything that's happening there is to fix real bugs in the kernel.
I'll look into ways how to fix this, but I am afraid this is going to be really tricky. Therefore we'd have to very likely proceed asap with revert of
09954bad448and coming up with a workaround that'd still avoid the bug reported by syzkaller.
Are we making any progress on fixing this regression? Anything I can do?
Regards
Mark