Resend: Another 4.4 to 4.5 floppy issue

Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

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 <jkosina@suse.cz>

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.

Cc: stable@vger.kernel.org # v4.5+
Reported-by: Wim Osterholt <wim@djo.tudelft.nl>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---

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(-)

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 84708a5..a1dcf12 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -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;

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

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Tue, 5 Jul 2016, Mark Hounschell wrote:

> From: Jiri Kosina <jkosina@suse.cz>
> 
> 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.
> 
> Cc: stable@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt <wim@djo.tudelft.nl>
> Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
[ ... snip ... ]
> 
> 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.

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,

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 07/11/2016 11:36 AM, Jiri Kosina wrote:
> On Tue, 5 Jul 2016, Mark Hounschell wrote:
>
>> From: Jiri Kosina <jkosina@suse.cz>
>>
>> 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.
>>
>> Cc: stable@vger.kernel.org # v4.5+
>> Reported-by: Wim Osterholt <wim@djo.tudelft.nl>
>> Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
>> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>> ---
> [ ... snip ... ]
>>
>> 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.
>
> 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,
>

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

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Mon, 11 Jul 2016, Mark Hounschell wrote:

> 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?

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.

> 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

> 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.

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 07/12/2016 04:54 AM, Jiri Kosina wrote:
> On Mon, 11 Jul 2016, Mark Hounschell wrote:
>
>> 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?
>
> 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.
>

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.

>> 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?

> 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
>
>> 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.
>

I would be happy to do some testing for you if needed. At least with 
regard to our apps.

Regards
Mark

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Wed, 13 Jul 2016, Mark Hounschell wrote:

> > 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.
> 
> 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.

> 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.

Yeah, that's check_disk_change().

> > > 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. 

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").

> > 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
> > 
> > > 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.
> 
> 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,

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 08/02/2016 05:44 AM, Jiri Kosina wrote:
> On Wed, 13 Jul 2016, Mark Hounschell wrote:
>
>>> 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.
>>
>> 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.
>
>> 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.
>
> Yeah, that's check_disk_change().
>
>>>> 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.
>
> 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").
>
>>> 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
>>>
>>>> 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.
>>
>> 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

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Wed, 3 Aug 2016, Mark Hounschell wrote:

> I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.

It's there.

> 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,

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 08/11/2016 09:24 AM, Jiri Kosina wrote:
> On Wed, 3 Aug 2016, Mark Hounschell wrote:
>
>> I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
>
> It's there.
>
>> 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

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Thu, 11 Aug 2016, Mark Hounschell wrote:

> 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,

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 08/12/2016 05:37 AM, Jiri Kosina wrote:
> On Thu, 11 Aug 2016, Mark Hounschell wrote:
>
>> 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

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Fri, 12 Aug 2016, Mark Hounschell wrote:

> > 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.

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Mark Hounschell]

On 07/12/2016 04:54 AM, Jiri Kosina wrote:
> On Mon, 11 Jul 2016, Mark Hounschell wrote:
>
>> 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?
>
> 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.
>
>> 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
>
>> 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.
>

Are we making any progress on fixing this regression? Anything I can do?

Regards
Mark