* Resend: Another 4.4 to 4.5 floppy issue
@ 2016-07-05 20:28 Mark Hounschell
2016-07-11 15:36 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-07-05 20:28 UTC (permalink / raw)
To: Linux-kernel; +Cc: Jiri Kosina
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-05 20:28 Resend: Another 4.4 to 4.5 floppy issue Mark Hounschell
@ 2016-07-11 15:36 ` Jiri Kosina
2016-07-11 17:05 ` Mark Hounschell
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2016-07-11 15:36 UTC (permalink / raw)
To: Mark Hounschell; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-11 15:36 ` Jiri Kosina
@ 2016-07-11 17:05 ` Mark Hounschell
2016-07-12 8:54 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-07-11 17:05 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-11 17:05 ` Mark Hounschell
@ 2016-07-12 8:54 ` Jiri Kosina
2016-07-13 12:14 ` Mark Hounschell
2016-08-23 17:01 ` Mark Hounschell
0 siblings, 2 replies; 13+ messages in thread
From: Jiri Kosina @ 2016-07-12 8:54 UTC (permalink / raw)
To: Mark Hounschell; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-12 8:54 ` Jiri Kosina
@ 2016-07-13 12:14 ` Mark Hounschell
2016-08-02 9:44 ` Jiri Kosina
2016-08-23 17:01 ` Mark Hounschell
1 sibling, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-07-13 12:14 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-13 12:14 ` Mark Hounschell
@ 2016-08-02 9:44 ` Jiri Kosina
2016-08-03 14:20 ` Mark Hounschell
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2016-08-02 9:44 UTC (permalink / raw)
To: Mark Hounschell; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-08-02 9:44 ` Jiri Kosina
@ 2016-08-03 14:20 ` Mark Hounschell
2016-08-11 13:24 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-08-03 14:20 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-08-03 14:20 ` Mark Hounschell
@ 2016-08-11 13:24 ` Jiri Kosina
2016-08-11 17:38 ` Mark Hounschell
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2016-08-11 13:24 UTC (permalink / raw)
To: Mark Hounschell; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-08-11 13:24 ` Jiri Kosina
@ 2016-08-11 17:38 ` Mark Hounschell
2016-08-12 9:37 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-08-11 17:38 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-08-11 17:38 ` Mark Hounschell
@ 2016-08-12 9:37 ` Jiri Kosina
2016-08-12 11:59 ` Mark Hounschell
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2016-08-12 9:37 UTC (permalink / raw)
To: Mark Hounschell; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-08-12 9:37 ` Jiri Kosina
@ 2016-08-12 11:59 ` Mark Hounschell
2016-08-12 12:09 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Mark Hounschell @ 2016-08-12 11:59 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Resend: Another 4.4 to 4.5 floppy issue
2016-07-12 8:54 ` Jiri Kosina
2016-07-13 12:14 ` Mark Hounschell
@ 2016-08-23 17:01 ` Mark Hounschell
1 sibling, 0 replies; 13+ messages in thread
From: Mark Hounschell @ 2016-08-23 17:01 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-08-23 17:01 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-05 20:28 Resend: Another 4.4 to 4.5 floppy issue Mark Hounschell
2016-07-11 15:36 ` Jiri Kosina
2016-07-11 17:05 ` Mark Hounschell
2016-07-12 8:54 ` Jiri Kosina
2016-07-13 12:14 ` Mark Hounschell
2016-08-02 9:44 ` Jiri Kosina
2016-08-03 14:20 ` Mark Hounschell
2016-08-11 13:24 ` Jiri Kosina
2016-08-11 17:38 ` Mark Hounschell
2016-08-12 9:37 ` Jiri Kosina
2016-08-12 11:59 ` Mark Hounschell
2016-08-12 12:09 ` Jiri Kosina
2016-08-23 17:01 ` Mark Hounschell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.