[RESEND3] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

Commit Message

Kirill Smelkov July 24, 2019, 9:46 a.m. UTC

Miklos,

I was sending this patch for ~1.5 month without any feedback from you[1,2,3].
The patch was tested by Sander Eikelenboom (original GlusterFS problem
reporter)[4], and you said that it will be ok to retry for next
cycle[5]. I was hoping for this patch to be picked up for 5.3 and queued
to Linus's tree, but in despite several resends from me (the same patch;
just reminders) nothing is happening. v5.3-rc1 came out on last Sunday,
which, in my understanding, denotes the close of 5.3 merge window. What
is going on? Could you please pick up the patch and handle it?

Thanks beforehand (again),
Kirill

[1] https://lore.kernel.org/linux-fsdevel/[e-mail]/
[2] https://lore.kernel.org/linux-fsdevel/[e-mail]/
[3] https://lore.kernel.org/linux-fsdevel/[e-mail]/
[4] https://lore.kernel.org/linux-fsdevel/[e-mail]/
[5] https://lore.kernel.org/linux-fsdevel/CAOssrKfj-MDujX0_t_fgobL_KwpuG2fxFmT=4nURuJA=[e-mail]/

---- 8< ----

[ This retries commit d4b13963f217 which was reverted in 766741fcaa1f.

  In this version we require only `sizeof(fuse_in_header) + sizeof(fuse_write_in)`
  instead of 4K for FUSE request header room, because, contrary to
  libfuse and kernel client behaviour, GlusterFS actually provides only
  so much room for request header. ]

A FUSE filesystem server queues /dev/fuse sys_read calls to get
filesystem requests to handle. It does not know in advance what would be
that request as it can be anything that client issues - LOOKUP, READ,
WRITE, ... Many requests are short and retrieve data from the
filesystem. However WRITE and NOTIFY_REPLY write data into filesystem.

Before getting into operation phase, FUSE filesystem server and kernel
client negotiate what should be the maximum write size the client will
ever issue. After negotiation the contract in between server/client is
that the filesystem server then should queue /dev/fuse sys_read calls with
enough buffer capacity to receive any client request - WRITE in
particular, while FUSE client should not, in particular, send WRITE
requests with > negotiated max_write payload. FUSE client in kernel and
libfuse historically reserve 4K for request header. However an existing
filesystem server - GlusterFS - was found which reserves only 80 bytes
for header room (= `sizeof(fuse_in_header) + sizeof(fuse_write_in)`).

https://lore.kernel.org/linux-fsdevel/[e-mail]/
https://github.com/gluster/glusterfs/blob/v3.8.15-0-gd174f021a/xlators/mount/fuse/src/fuse-bridge.c#L4894

Since

	`sizeof(fuse_in_header) + sizeof(fuse_write_in)` ==
	`sizeof(fuse_in_header) + sizeof(fuse_read_in)`  ==
	`sizeof(fuse_in_header) + sizeof(fuse_notify_retrieve_in)`

is the absolute minimum any sane filesystem should be using for header
room, the contract is that filesystem server should queue sys_reads with
`sizeof(fuse_in_header) + sizeof(fuse_write_in)` + max_write buffer.

If the filesystem server does not follow this contract, what can happen
is that fuse_dev_do_read will see that request size is > buffer size,
and then it will return EIO to client who issued the request but won't
indicate in any way that there is a problem to filesystem server.
This can be hard to diagnose because for some requests, e.g. for
NOTIFY_REPLY which mimics WRITE, there is no client thread that is
waiting for request completion and that EIO goes nowhere, while on
filesystem server side things look like the kernel is not replying back
after successful NOTIFY_RETRIEVE request made by the server.

We can make the problem easy to diagnose if we indicate via error return to
filesystem server when it is violating the contract.  This should not
practically cause problems because if a filesystem server is using shorter
buffer, writes to it were already very likely to cause EIO, and if the
filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER
minimum buffer size.

Please see [1] for context where the problem of stuck filesystem was hit
for real (because kernel client was incorrectly sending more than
max_write data with NOTIFY_REPLY; see also previous patch), 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

Signed-off-by: Kirill Smelkov <[e-mail]>
Tested-by: Sander Eikelenboom <[e-mail]>
Cc: Han-Wen Nienhuys <[e-mail]>
Cc: Jakob Unterwurzacher <[e-mail]>
---
 fs/fuse/dev.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Comments

Miklos Szeredi Aug. 1, 2019, 10:35 a.m. UTC | #1

On Wed, Jul 24, 2019 at 11:46 AM Kirill Smelkov <[e-mail]> wrote:
>
> Miklos,
>
> I was sending this patch for ~1.5 month without any feedback from you[1,2,3].
> The patch was tested by Sander Eikelenboom (original GlusterFS problem
> reporter)[4], and you said that it will be ok to retry for next
> cycle[5]. I was hoping for this patch to be picked up for 5.3 and queued
> to Linus's tree, but in despite several resends from me (the same patch;
> just reminders) nothing is happening. v5.3-rc1 came out on last Sunday,
> which, in my understanding, denotes the close of 5.3 merge window. What
> is going on? Could you please pick up the patch and handle it?

Applied.

Thanks,
Miklos

Kirill Smelkov Aug. 1, 2019, 1:50 p.m. UTC | #2

On Thu, Aug 01, 2019 at 12:35:03PM +0200, Miklos Szeredi wrote:
> On Wed, Jul 24, 2019 at 11:46 AM Kirill Smelkov <[e-mail]> wrote:
> >
> > Miklos,
> >
> > I was sending this patch for ~1.5 month without any feedback from you[1,2,3].
> > The patch was tested by Sander Eikelenboom (original GlusterFS problem
> > reporter)[4], and you said that it will be ok to retry for next
> > cycle[5]. I was hoping for this patch to be picked up for 5.3 and queued
> > to Linus's tree, but in despite several resends from me (the same patch;
> > just reminders) nothing is happening. v5.3-rc1 came out on last Sunday,
> > which, in my understanding, denotes the close of 5.3 merge window. What
> > is going on? Could you please pick up the patch and handle it?
> 
> Applied.

Thanks...

Patch

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index ea8237513dfa..b2b2344eadcf 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1317,6 +1317,26 @@  static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
 	unsigned reqsize;
 	unsigned int hash;
 
+	/*
+	 * Require sane minimum read buffer - that has capacity for fixed part
+	 * of any request header + negotiated max_write room for data. If the
+	 * requirement is not satisfied return EINVAL to the filesystem server
+	 * to indicate that it is not following FUSE server/client contract.
+	 * Don't dequeue / abort any request.
+	 *
+	 * Historically libfuse reserves 4K for fixed header room, but e.g.
+	 * GlusterFS reserves only 80 bytes
+	 *
+	 *	= `sizeof(fuse_in_header) + sizeof(fuse_write_in)`
+	 *
+	 * which is the absolute minimum any sane filesystem should be using
+	 * for header room.
+	 */
+	if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER,
+			   sizeof(struct fuse_in_header) + sizeof(struct fuse_write_in) +
+				fc->max_write))
+		return -EINVAL;
+
  restart:
 	spin_lock(&fiq->waitq.lock);
 	err = -EAGAIN;