On Tue, 2025-03-11 at 17:15 +0000, Al Viro wrote:

On Tue, Mar 11, 2025 at 12:20:05PM -0400, James Bottomley wrote:

quoted

That's the way it's supposed to work, yes.  However, if we move to
an always persistent superblock and mnt, I was thinking there'd
have to be an indicator in the sfi about whether the variables were
reflected or not.

Just have a pointer to superblock set at ->get_tree() and cleared at
the very beginning of ->kill_sb(), then have notifier bugger off if
that thing's NULL or if atomic_inc_not_zero(sb->s_active) fails
(rcu_read_lock() is sufficient for memory safety of that).  And
do deactivate_super() when you are done.

OK that works, thanks!

That'll give you exclusion with umount.  As for the rest of that...
fuck it, just have kern_mount()/kern_unmount() inside that.
How hot do you expect that notifier chain to be?

The notifier chain itself is somewhat active, but the notifications we
care about occur once on resume from hibernate (so very few, if any).

Or screw playing with open/iterate_dir, but that'll need some
thinking -
theoretically everything you need is already accessible, but direct
access to ->d_lock/->d_sib in there is almost certainly not the right
level of abstraction.  We already have similar bits and pieces
in autofs and ceph, and it's just a matter of figuring out a good
set of primitives.

I'll probably stick to getting it to work for now ... the refactoring
can come later.

Regards,

James