diff options
author | Jiri Kosina <jkosina@suse.cz> | 2016-02-06 23:00:22 +0100 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.cz> | 2016-02-06 23:00:22 +0100 |
commit | 09954bad448791ef01202351d437abdd9497a804 (patch) | |
tree | e44a5262e04f1a19a4bfbfc5ba82d9bc440b4f5d /block/ioctl.c | |
parent | bf64318564c43385ffc3d3dfedab5287bdf3dfdd (diff) | |
download | op-kernel-dev-09954bad448791ef01202351d437abdd9497a804.zip op-kernel-dev-09954bad448791ef01202351d437abdd9497a804.tar.gz |
floppy: refactor open() flags handling
In case /dev/fdX is open with O_NDELAY / O_NONBLOCK, floppy_open() immediately
succeeds, without performing any further media / controller preparations.
That's "correct" wrt. the NODELAY flag, but is hardly correct wrt. the rest
of the floppy driver, that is not really O_NONBLOCK ready, at all. Therefore
it's not too surprising, that subsequent attempts to work with the
filedescriptor produce bad results. Namely, syzkaller tool has been able
to livelock mmap() on the returned fd to keep waiting on the page unlock
bit forever.
Quite frankly, I have trouble defining what non-blocking behavior would be for
floppies. Is waiting ages for the driver to actually succeed reading a sector
blocking operation? Is waiting for drive motor to start blocking operation? How
about in case of virtualized floppies?
One option would be returning EWOULDBLOCK in case O_NDLEAY / O_NONBLOCK is
being passed to open(). That has a theoretical potential of breaking some
arcane and archaic userspace though.
Let's take a more conservative aproach, and accept the O_NDLEAY flag, and let
the driver behave as usual.
While at it, clean up a bit handling of !(mode & (FMODE_READ|FMODE_WRITE))
case and return EINVAL instead of succeeding as well.
Spotted by syzkaller tool.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'block/ioctl.c')
0 files changed, 0 insertions, 0 deletions