linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).