aboutsummaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorKirill Smelkov <kirr@nexedi.com>2019-03-27 10:15:19 +0000
committerPaul Gortmaker <paul.gortmaker@windriver.com>2019-09-16 12:20:52 -0400
commit9ed25c04cbf9af346ff7c88b87113a44ff65fba5 (patch)
tree94df13ec25fb77be4e86fc69cf1a2adbd280bace /fs
parentbe463fc316e92326fd43acc1f9ba16f082966593 (diff)
downloadlinux-yocto-9ed25c04cbf9af346ff7c88b87113a44ff65fba5.tar.gz
linux-yocto-9ed25c04cbf9af346ff7c88b87113a44ff65fba5.tar.bz2
linux-yocto-9ed25c04cbf9af346ff7c88b87113a44ff65fba5.zip
fuse: retrieve: cap requested size to negotiated max_write
commit 7640682e67b33cab8628729afec8ca92b851394f upstream. FUSE filesystem server and kernel client negotiate during initialization phase, what should be the maximum write size the client will ever issue. Correspondingly the filesystem server then queues sys_read calls to read requests with buffer capacity large enough to carry request header + that max_write bytes. A filesystem server is free to set its max_write in anywhere in the range between [1*page, fc->max_pages*page]. In particular go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages corresponds to 128K. Libfuse also allows users to configure max_write, but by default presets it to possible maximum. If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we allow to retrieve more than max_write bytes, corresponding prepared NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the filesystem server, in full correspondence with server/client contract, will be only queuing sys_read with ~max_write buffer capacity, and fuse_dev_do_read throws away requests that cannot fit into server request buffer. In turn the filesystem server could get stuck waiting indefinitely for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is understood by clients as that NOTIFY_REPLY was queued and will be sent back. Cap requested size to negotiate max_write to avoid the problem. This aligns with the way NOTIFY_RETRIEVE handler works, which already unconditionally caps requested retrieve size to fuse_conn->max_pages. This way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than was originally requested. Please see [1] for context where the problem of stuck filesystem was hit for real, how the situation was traced and for more involving patch that did not make it into the tree. [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 [2] https://github.com/hanwen/go-fuse Signed-off-by: Kirill Smelkov <kirr@nexedi.com> Cc: Han-Wen Nienhuys <hanwen@google.com> Cc: Jakob Unterwurzacher <jakobunt@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Diffstat (limited to 'fs')
-rw-r--r--fs/fuse/dev.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 86dfc9e5e45f..0af74f8f58e0 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1677,7 +1677,7 @@ static int fuse_retrieve(struct fuse_conn *fc, struct inode *inode,
offset = outarg->offset & ~PAGE_MASK;
file_size = i_size_read(inode);
- num = outarg->size;
+ num = min(outarg->size, fc->max_write);
if (outarg->offset > file_size)
num = 0;
else if (outarg->offset + num > file_size)