Messages in this thread | | | From | Daniil Lunev <> | Date | Mon, 30 May 2022 11:41:30 +1000 | 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@chromium.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
| |