Re: [PATCH 2/3] super: wait for nascent superblocks

[Christian Brauner <brauner@kernel.org>]

On Thu, Aug 17, 2023 at 09:53:43PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 17, 2023 at 02:50:21PM +0200, Jan Kara wrote:
> > > +/**
> > > + * super_wait - wait for superblock to become ready
> > > + * @sb: superblock to wait for
> > > + * @excl: whether exclusive access is required
> > > + *
> > > + * If the superblock has neither passed through vfs_get_tree() or
> > > + * generic_shutdown_super() yet wait for it to happen. Either superblock
> > > + * creation will succeed and SB_BORN is set by vfs_get_tree() or we're
> > > + * woken and we'll see SB_DYING.
> > > + *
> > > + * The caller must have acquired a temporary reference on @sb->s_count.
> > > + *
> > > + * Return: true if SB_BORN was set, false if SB_DYING was set.
> > 
> > The comment should mention that this acquires s_umount and returns with it
> > held. Also the name is a bit too generic for my taste and not expressing
> > the fact this is in fact a lock operation. Maybe something like
> > super_lock_wait_born()?
> 
> Isn't this actually the normal function we want people to call?  So maybe
> this function should be called super_lock() and the functions in the
> last patch get called __super_lock() for raw access to the lock.

I think that's a good point. I've renamed them accordingly.

> 
> I'm also a little wary that this isn't _killable.  Are we guaranteed
> that a superblock will transition to BORN or DYING within a limited
> time?

Yes, it should. If this would be an issue it's something we should have
seen already. Random example being s_umount being held over a
filesytem's fill_super() method all while concurrent iterators are
sleeping on s_umount unconditionally. It is ofc always possible for us
to make this killable in the future should it become an issue.