]> git.baikalelectronics.ru Git - kernel.git/commit
Revert "vfs: properly and reliably lock f_pos in fdget_pos()"
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 26 Nov 2019 19:34:06 +0000 (11:34 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Tue, 26 Nov 2019 19:34:06 +0000 (11:34 -0800)
commit69e135bd04d9d119d57ee21e1c2d67981ae2f191
tree66883d9effd4dabf661d52407e5131a89cc8d71e
parent066bf24af74b70ec030a26a68158e00593f3c509
Revert "vfs: properly and reliably lock f_pos in fdget_pos()"

This reverts commit 6eaca83539dc8257dbaa48e3fb3b6ed0b986700e.

I was hoping it would be benign to switch over entirely to FMODE_STREAM,
and we'd have just a couple of small fixups we'd need, but it looks like
we're not quite there yet.

While it worked fine on both my desktop and laptop, they are fairly
similar in other respects, and run mostly the same loads.  Kenneth
Crudup reports that it seems to break both his vmware installation and
the KDE upower service.  In both cases apparently leading to timeouts
due to waitinmg for the f_pos lock.

There are a number of character devices in particular that definitely
want stream-like behavior, but that currently don't get marked as
streams, and as a result get the exclusion between concurrent
read()/write() on the same file descriptor.  Which doesn't work well for
them.

The most obvious example if this is /dev/console and /dev/tty, which use
console_fops and tty_fops respectively (and ptmx_fops for the pty master
side).  It may be that it's just this that causes problems, but we
clearly weren't ready yet.

Because there's a number of other likely common cases that don't have
llseek implementations and would seem to act as stream devices:

  /dev/fuse (fuse_dev_operations)
  /dev/mcelog (mce_chrdev_ops)
  /dev/mei0 (mei_fops)
  /dev/net/tun (tun_fops)
  /dev/nvme0 (nvme_dev_fops)
  /dev/tpm0 (tpm_fops)
  /proc/self/ns/mnt (ns_file_operations)
  /dev/snd/pcm* (snd_pcm_f_ops[])

and while some of these could be trivially automatically detected by the
vfs layer when the character device is opened by just noticing that they
have no read or write operations either, it often isn't that obvious.

Some character devices most definitely do use the file position, even if
they don't allow seeking: the firmware update code, for example, uses
simple_read_from_buffer() that does use f_pos, but doesn't allow seeking
back and forth.

We'll revisit this when there's a better way to detect the problem and
fix it (possibly with a coccinelle script to do more of the FMODE_STREAM
annotations).

Reported-by: Kenneth R. Crudup <kenny@panix.com>
Cc: Kirill Smelkov <kirr@nexedi.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/file.c
fs/open.c
include/linux/fs.h