Commit 9c225f2655 ("vfs: atomic f_pos accesses as per POSIX") may have
gone a little too far: We've had a report of a deadlock of an
application accessing a /proc file through the same file descriptor
from multiple threads. While /proc files are regular ones, them (and
similarly others which are) often not being seekable really already
makes them deviate from how regular files would behave.
The issue was specifically observed on /proc/xen/xenbus (which doesn't
exist in the upstream kernel), when an application's read blocks
(waiting for a watch to trigger) while the write that would satisfy
the read then waits for the position update mutex to be released.
Since for non-seekable files the file position is kind of a strange
thing anyway, also don't enforce atomic position updates for them.
(I do recognize that the application isn't really standard conforming,
as it should use multiple file descriptors from all I understand. But
it worked fine before that change, and so they claim the kernel to be
at fault.)
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
---
v2: Add a paragraph to the description outlining the actual issue
observed.
---
fs/open.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 4.6-rc2/fs/open.c
+++ 4.6-rc2-nonseekable-no-atomic-pos/fs/open.c
@@ -1142,7 +1142,8 @@ EXPORT_SYMBOL(generic_file_open);
*/
int nonseekable_open(struct inode *inode, struct file *filp)
{
- filp->f_mode &= ~(FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE);
+ filp->f_mode &= ~(FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE |
+ FMODE_ATOMIC_POS);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
