From: Jan Kara <jack@suse.cz>
To: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.com>, Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/3] super: wait until we passed kill super
Date: Thu, 17 Aug 2023 16:37:36 +0200 [thread overview]
Message-ID: <20230817143736.u22c5o5sesojlo3y@quack3> (raw)
In-Reply-To: <20230817-vfs-super-fixes-v3-v1-3-06ddeca7059b@kernel.org>
On Thu 17-08-23 12:47:44, 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>
> ---
> fs/super.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++-----
> include/linux/fs.h | 1 +
> 2 files changed, 66 insertions(+), 6 deletions(-)
<snip>
> @@ -456,6 +497,25 @@ void deactivate_locked_super(struct super_block *s)
> list_lru_destroy(&s->s_dentry_lru);
> list_lru_destroy(&s->s_inode_lru);
>
> + /*
> + * Remove it from @fs_supers so it isn't found by new
> + * sget{_fc}() walkers anymore. Any concurrent mounter still
> + * managing to grab a temporary reference is guaranteed to
> + * already see SB_DYING and will wait until we notify them about
> + * SB_DEAD.
> + */
> + spin_lock(&sb_lock);
> + hlist_del_init(&s->s_instances);
> + spin_unlock(&sb_lock);
> +
> + /*
> + * Let concurrent mounts know that this thing is really dead.
> + * We don't need @sb->s_umount here as every concurrent caller
> + * will see SB_DYING and either discard the superblock or wait
> + * for SB_DEAD.
> + */
> + super_wake(s, SB_DEAD);
> +
> put_filesystem(fs);
> put_super(s);
> } else {
> @@ -638,15 +698,14 @@ void generic_shutdown_super(struct super_block *sb)
> spin_unlock(&sb->s_inode_list_lock);
> }
> }
> - spin_lock(&sb_lock);
> - /* should be initialized for __put_super_and_need_restart() */
> - hlist_del_init(&sb->s_instances);
> - spin_unlock(&sb_lock);
OK, but we have several checks of hlist_unhashed(&sb->s_instances) in the
code whose meaning is now subtly changed. We have:
trylock_super() - needs SB_DYING check instead of s_instances check
__iterate_supers() - probably we should add SB_DYING check to not block
emergency operations on s_umount unnecessarily and drop s_instances
check
iterate_supers() - we can drop s_instances check
get_super() - we can drop s_instances check
get_active_super() - we can drop s_instances check
user_get_super() - we can drop s_instances check
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-08-17 14:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 10:47 [PATCH 0/3] super: allow waiting without s_umount held Christian Brauner
2023-08-17 10:47 ` [PATCH 1/3] super: use super_{lock,unlock}() Christian Brauner
2023-08-17 11:39 ` Jan Kara
2023-08-17 10:47 ` [PATCH 2/3] super: wait for nascent superblocks Christian Brauner
2023-08-17 12:50 ` Jan Kara
2023-08-17 13:24 ` Christian Brauner
2023-08-17 13:41 ` Christian Brauner
2023-08-17 14:16 ` Jan Kara
2023-08-17 14:30 ` Christian Brauner
2023-08-17 20:53 ` Matthew Wilcox
2023-08-18 10:56 ` Christian Brauner
2023-08-17 10:47 ` [PATCH 3/3] super: wait until we passed kill super Christian Brauner
2023-08-17 14:37 ` Jan Kara [this message]
2023-08-17 14:54 ` Christian Brauner
2023-08-17 16:27 ` Jan Kara
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=20230817143736.u22c5o5sesojlo3y@quack3 \
--to=jack@suse.cz \
--cc=brauner@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.com \
--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).