From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] super: wait until we passed kill super
Date: Fri, 18 Aug 2023 14:48:16 +0200 [thread overview]
Message-ID: <20230818-umbruch-wahldebakel-ec87b7549afd@brauner> (raw)
In-Reply-To: <20230818122609.kzuw76wqz4plmsyb@quack3>
On Fri, Aug 18, 2023 at 02:26:09PM +0200, Jan Kara wrote:
> On Fri 18-08-23 12:54:18, Christian Brauner wrote:
> > Recent rework moved block device closing out of sb->put_super() and into
> > sb->kill_sb() to avoid deadlocks as s_umount is held in put_super() and
> > blkdev_put() can end up taking s_umount again.
> >
> > That means we need to move the removal of the superblock from @fs_supers
> > out of generic_shutdown_super() and into deactivate_locked_super() to
> > ensure that concurrent mounters don't fail to open block devices that
> > are still in use because blkdev_put() in sb->kill_sb() hasn't been
> > called yet.
> >
> > We can now do this as we can make iterators through @fs_super and
> > @super_blocks wait without holding s_umount. Concurrent mounts will wait
> > until a dying superblock is fully dead so until sb->kill_sb() has been
> > called and SB_DEAD been set. Concurrent iterators can already discard
> > any SB_DYING superblock.
> >
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
>
> One nit below:
>
> > +static inline bool wait_dead(struct super_block *sb)
> > +{
> > + unsigned int flags;
> > +
> > + /*
> > + * Pairs with smp_store_release() in super_wake() and ensures
> > + * that we see SB_DEAD after we're woken.
> > + */
> > + flags = smp_load_acquire(&sb->s_flags);
> > + return flags & SB_DEAD;
> > +}
> > +
> > /**
> > * super_lock - wait for superblock to become ready
> > * @sb: superblock to wait for
> > @@ -140,6 +152,33 @@ static bool super_lock(struct super_block *sb, bool excl)
> > goto relock;
> > }
> >
> > +/**
> > + * super_lock_dead - wait for superblock to become ready or fully dead
> > + * @sb: superblock to wait for
> > + *
> > + * Wait for a superblock to be SB_BORN or to be SB_DEAD. In other words,
> > + * don't just wait for the superblock to be shutdown in
> > + * generic_shutdown_super() but actually wait until sb->kill_sb() has
> > + * finished.
> > + *
> > + * The caller must have acquired a temporary reference on @sb->s_count.
> > + *
> > + * Return: This returns true if SB_BORN was set, false if SB_DEAD was
> > + * set. The function acquires s_umount and returns with it held.
> > + */
> > +static bool super_lock_dead(struct super_block *sb)
> > +{
> > + if (super_lock(sb, true))
> > + return true;
> > +
> > + lockdep_assert_held(&sb->s_umount);
> > + super_unlock_excl(sb);
> > + /* If superblock is dying, wait for everything to be shutdown. */
> > + wait_var_event(&sb->s_flags, wait_dead(sb));
> > + __super_lock_excl(sb);
> > + return false;
> > +}
> > +
> > /* wait and acquire read-side of @sb->s_umount */
> > static inline bool super_lock_shared(struct super_block *sb)
> > {
> > @@ -153,7 +192,7 @@ static inline bool super_lock_excl(struct super_block *sb)
> > }
> >
> > /* wake waiters */
> > -#define SUPER_WAKE_FLAGS (SB_BORN | SB_DYING)
> > +#define SUPER_WAKE_FLAGS (SB_BORN | SB_DYING | SB_DEAD)
> > static void super_wake(struct super_block *sb, unsigned int flag)
> > {
> > unsigned int flags = sb->s_flags;
> > @@ -169,6 +208,35 @@ static void super_wake(struct super_block *sb, unsigned int flag)
> > wake_up_var(&sb->s_flags);
> > }
> >
> > +/**
> > + * grab_super_dead - acquire an active reference to a superblock
> > + * @sb: superblock to acquire
> > + *
> > + * Acquire a temporary reference on a superblock and try to trade it for
> > + * an active reference. This is used in sget{_fc}() to wait for a
> > + * superblock to either become SB_BORN or for it to pass through
> > + * sb->kill() and be marked as SB_DEAD.
> > + *
> > + * Return: This returns true if an active reference could be acquired,
> > + * false if not. The function acquires s_umount and returns with
> > + * it held.
> > + */
> > +static bool grab_super_dead(struct super_block *s) __releases(sb_lock)
> > +{
> > + bool born;
> > +
> > + s->s_count++;
> > + spin_unlock(&sb_lock);
> > + born = super_lock_dead(s);
> > + if (born && atomic_inc_not_zero(&s->s_active)) {
> > + put_super(s);
> > + return true;
> > + }
> > + up_write(&s->s_umount);
> > + put_super(s);
> > + return false;
> > +}
> > +
>
> As I'm looking at it now, I'm wondering whether we are not overdoing it a
> bit. Why not implement grab_super_dead() as:
>
> static bool grab_super_dead(struct super_block *s) __releases(sb_lock)
> {
> s->s_count++;
> if (grab_super(s))
> return true;
> wait_var_event(&sb->s_flags, wait_dead(sb));
> put_super(s);
> return false;
> }
Sounds good. Thanks for the suggestion.
>
> And just remove super_lock_dead() altogether? I don't expect more users of
> that functionality...
Famous last words... :)
prev parent reply other threads:[~2023-08-18 12:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-18 10:54 [PATCH v2 0/4] super: allow waiting without s_umount held Christian Brauner
2023-08-18 10:54 ` [PATCH v2 1/4] super: use locking helpers Christian Brauner
2023-08-18 11:08 ` Jan Kara
2023-08-18 10:54 ` [PATCH v2 2/4] super: make locking naming consistent Christian Brauner
2023-08-18 11:08 ` Jan Kara
2023-08-18 10:54 ` [PATCH v2 3/4] super: wait for nascent superblocks Christian Brauner
2023-08-18 12:02 ` Jan Kara
2023-08-18 12:46 ` Christian Brauner
2023-08-18 13:06 ` Jan Kara
2023-08-18 10:54 ` [PATCH v2 4/4] super: wait until we passed kill super Christian Brauner
2023-08-18 12:26 ` Jan Kara
2023-08-18 12:48 ` Christian Brauner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230818-umbruch-wahldebakel-ec87b7549afd@brauner \
--to=brauner@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).