Messages in this thread | | | Date | Mon, 26 Sep 2022 08:17:10 -0600 | From | Tycho Andersen <> | Subject | Re: [PATCH] fuse: In fuse_flush only wait if someone wants the return code |
| |
Hi,
On Mon, Sep 19, 2022 at 09:03:47AM -0600, Tycho Andersen wrote: > Hi Miklos, > > On Thu, Sep 01, 2022 at 08:06:47AM -0600, Tycho Andersen wrote: > > From: "Eric W. Biederman" <ebiederm@xmission.com> > > > > In my very light testing this resolves a hang where a thread of the > > fuse server was accessing the fuse filesystem (the fuse server is > > serving up), when the fuse server is killed. > > > > The practical problem is that the fuse server file descriptor was > > being closed after the file descriptor into the fuse filesystem so > > that the fuse filesystem operations were being blocked for instead of > > being aborted. Simply skipping the unnecessary wait resolves this > > issue. > > > > This is just a proof of concept and someone should look to see if the > > fuse max_background limit could cause a problem with this approach. > > > > Additionally testing PF_EXITING is a very crude way to tell if someone > > wants the return code from the vfs flush operation. As such in the > > long run it probably makes sense to get some direct vfs support for > > knowing if flush needs to block until all of the flushing is complete > > and a status/return code can be returned. > > > > Unless I have missed something this is a generic optimization that can > > apply to many network filesystems. > > > > Al, vfs folks? (igrab/iput sorted so as not to be distractions). > > > > Perhaps a .flush_async method without a return code and a > > filp_close_async function without a return code to take advantage of > > this in the general sense. > > > > Waiting potentially indefinitely for user space in do_exit seems like a > > bad idea. Especially when all that the wait is for is to get a return > > code that will never be examined. > > > > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > [tycho: small fixups for releasing fuse file + nocred flag] > > Signed-off-by: Tycho Andersen <tycho@tycho.pizza> > > Reported-by: Tycho Andersen <tycho@tycho.pizza> > > Tested-by: "Serge E. Hallyn" <serge@hallyn.com> > > Any chance you're willing to take this patch? We're still seeing this > a lot and it would be great to get it fixed.
Another ping here, can someone take this? Miklos?
Thanks,
Tycho
| |