On Thu, Apr 08, 2021 at 01:49:35PM -0700, Daniel Xu wrote: > Ah right, sorry. Nobody will clean up the super_block. > > > IOW, NAK. The objects you are playing with have non-trivial lifecycle > > and poking into the guts of data structures without bothering to > > understand it is not a good idea. > > > > Rule of the thumb: if your code ends up using fields that are otherwise > > handled by a small part of codebase, the odds are that you need to be > > bloody careful. In particular, ->ns_lock has 3 users - all in > > fs/namespace.c. ->list/->mnt_list: all users in fs/namespace.c and > > fs/pnode.c. ->s_active: majority in fs/super.c, with several outliers > > in filesystems and safety of those is not trivial. > > > > Any time you see that kind of pattern, you are risking to reprise > > a scene from The Modern Times - the one with Charlie taking a trip > > through the guts of machinery. > > I'll take a closer look at the lifetime semantics. > > Hopefully the overall goal of the patch is ok. Happy to iterate on the > implementation details until it's correct. That depends. Note that bumping ->s_active means that umount of that sucker will *NOT* shut it down - that would happen only on the thread doing the final deactivation. What's more, having e.g. a USB stick mounted, doing umount(1), having it complete successfully, pulling the damn thing out and getting writes lost would make for a nasty surprise for users. With your approach it seems to be inevitable. Holding namespace_sem through the entire thing would prevent that, but's it's a non-starter for other reasons (starting with "it's a system-wide lock, so that'd be highly antisocial"). Are there any limits on what could be done to the pages, anyway? Because if it's "anything user wanted to do", it's *really* not feasible.
