linux-kernel - Re: [PATCH] fuse: In fuse_flush only wait if someone wants the return code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YyiEzbTDZ+g9iAas@tycho.pizza>
Date:   Mon, 19 Sep 2022 09:03:41 -0600
From:   Tycho Andersen <tycho@...ho.pizza>
To:     Miklos Szeredi <miklos@...redi.hu>,
        Eric Biederman <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH] fuse: In fuse_flush only wait if someone wants the
 return code

Hi Miklos,

On Thu, Sep 01, 2022 at 08:06:47AM -0600, Tycho Andersen wrote:
> From: "Eric W. Biederman" <ebiederm@...ssion.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@...ssion.com>
> [tycho: small fixups for releasing fuse file + nocred flag]
> Signed-off-by: Tycho Andersen <tycho@...ho.pizza>
> Reported-by: Tycho Andersen <tycho@...ho.pizza>
> Tested-by: "Serge E. Hallyn" <serge@...lyn.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.

Thanks.

Tycho