From: Kirill Smelkov <email@example.com> To: Miklos Szeredi <firstname.lastname@example.org> Cc: Miklos Szeredi <email@example.com>, Han-Wen Nienhuys <firstname.lastname@example.org>, Jakob Unterwurzacher <email@example.com>, Kirill Tkhai <firstname.lastname@example.org>, Andrew Morton <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, fuse-devel <firstname.lastname@example.org> Subject: Re: [RESEND4, PATCH 2/2] fuse: require /dev/fuse reads to have enough buffer capacity as negotiated Date: Wed, 24 Apr 2019 11:58:19 +0000 [thread overview] Message-ID: <20190424115815.GB2723@deco.navytux.spb.ru> (raw) In-Reply-To: <CAJfpegurLOLoNd9p2avcXPhSvP+ux8V+A=ghBySSpn0pX_Afpg@mail.gmail.com> On Wed, Apr 24, 2019 at 12:48:36PM +0200, Miklos Szeredi wrote: > On Wed, Mar 27, 2019 at 11:44 AM Kirill Smelkov <email@example.com> wrote: > > > > 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. This way the > > contract is that filesystem server should queue sys_reads with > > 4K+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 > > 8K minimum buffer size (= either FUSE_MIN_READ_BUFFER, see 1d3d752b47, > > or = 4K + min(max_write)=4k cared to be so by process_init_reply). > > > > Please see  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. > > > >  https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 > > Applied. Thanks. Looking forward for it to appear in fuse.git#for-next Kirill
next prev parent reply other threads:[~2019-04-24 12:26 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-27 10:15 [RESEND4, PATCH 0/2] fuse: don't stuck clients on retrieve_notify with size > max_write Kirill Smelkov 2019-03-27 10:15 ` [RESEND4, PATCH 2/2] fuse: require /dev/fuse reads to have enough buffer capacity as negotiated Kirill Smelkov 2019-04-24 10:48 ` Miklos Szeredi 2019-04-24 11:58 ` Kirill Smelkov [this message] 2019-03-27 10:15 ` [RESEND4, PATCH 1/2] fuse: retrieve: cap requested size to negotiated max_write Kirill Smelkov 2019-04-24 10:44 ` Miklos Szeredi 2019-04-24 11:56 ` Kirill Smelkov 2019-04-24 12:17 ` Miklos Szeredi 2019-04-24 12:31 ` Kirill Smelkov 2019-04-24 13:19 ` Miklos Szeredi 2019-04-24 14:22 ` Kirill Smelkov 2019-04-24 15:02 ` Miklos Szeredi 2019-04-24 18:10 ` Kirill Smelkov 2019-04-24 18:59 ` Kirill Smelkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190424115815.GB2723@deco.navytux.spb.ru \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RESEND4, PATCH 2/2] fuse: require /dev/fuse reads to have enough buffer capacity as negotiated' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).