linux-kernel - Re: [PATCH v2 2/2] FUSE: Retire superblock on force unmount

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] [day] [month] [year] [list]

Date:   Mon, 30 May 2022 11:41:30 +1000
From:   Daniil Lunev <dlunev@...omium.org>
To:     Miklos Szeredi <miklos@...redi.hu>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     linux-fsdevel@...r.kernel.org,
        Christoph Hellwig <hch@...radead.org>,
        fuse-devel <fuse-devel@...ts.sourceforge.net>,
        "Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] FUSE: Retire superblock on force unmount

I have prepared the v3 patch as described in my previous email. PTAL.

Thanks,
Daniil

On Wed, May 25, 2022 at 8:44 AM Daniil Lunev <dlunev@...omium.org> wrote:
>
> > Calling bdi_unregister() might be okay, and that should fix this.  I'm
> > not familiar enough with that part to say for sure.
> > But freeing sb->s_bdi while the superblock is active looks problematic.
> Tracing the code, I see that, yes, in general that might not be safe to call
> the "bdi_put" function for any FS - because it might have in-flight ops even
> with force, where they will routinely access the members of the bdi struct
> without locks. However, we do replace the struct with a no_op version,
> and specifically for the FUSE case we sever the connection first, so no
> in-flight ops can actually be there. And I am not sure if other FS may
> need to do this retirement, given they don't have these
> user-space/kernel split. It would make sense however to delay the actual
> put till  the actual super block destruction, but that would require
> introducing extra state tracking to see if the block is or is not registered
> anymore. It can be piggybacked on the v1 patch where I have an explicit
> state flag, but not on v2.
> Miklos, Al, will the following work and be acceptable?
> Get v1 patchset[1], in fuse_umount_begin do bdi_unregister and set
> the flag, but do not do bdi_put or replacement with no_op. And then in
> generic shutdown super if the bdi is not no_op and the 'defunct' flag is
> set, skip unregister part.
> Thanks,
> Daniil
>
> [1]
> https://lore.kernel.org/linux-fsdevel/20220511013057.245827-1-dlunev@chromium.org/T/#u