]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
floppy: refactor open() flags handling
authorJiri Kosina <jkosina@suse.cz>
Sat, 6 Feb 2016 22:00:22 +0000 (23:00 +0100)
committerJiri Kosina <jkosina@suse.cz>
Sat, 6 Feb 2016 22:00:22 +0000 (23:00 +0100)
commit09954bad448791ef01202351d437abdd9497a804
treee44a5262e04f1a19a4bfbfc5ba82d9bc440b4f5d
parentbf64318564c43385ffc3d3dfedab5287bdf3dfdd
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>
drivers/block/floppy.c