From: "Darrick J. Wong" <djwong@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Christian Brauner <brauner@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the djw-vfs tree
Date: Mon, 21 Aug 2023 19:51:20 -0700 [thread overview]
Message-ID: <20230822025120.GA11286@frogsfrogsfrogs> (raw)
In-Reply-To: <20230822110551.6386dd5d@canb.auug.org.au>
On Tue, Aug 22, 2023 at 11:05:51AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
>
> fs/super.c
>
> between commits:
>
> 880b9577855e ("fs: distinguish between user initiated freeze and kernel initiated freeze")
> 59ba4fdd2d1f ("fs: wait for partially frozen filesystems")
>
> from the djw-vfs tree and commits:
>
> 0ed33598ddf3 ("super: use locking helpers")
> 5e8749141521 ("super: wait for nascent superblocks")
>
> from the vfs-brauner tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
That looks correct, thank you.
Christian: I've been planning to merge the {freeze,thaw}_super @who
changes for 6.6; do you think more 'cooperating with the maintainer' is
needed, or shall I simply push my branch to Linus with a note that
s/down_write/super_lock_excl/ s/up_write/super_unlock_excl is needed to
resolve the merge the conflict?
--D
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/super.c
> index da68584815e4,a00e9f706f0f..000000000000
> --- a/fs/super.c
> +++ b/fs/super.c
> @@@ -1027,12 -1196,13 +1196,13 @@@ void emergency_remount(void
>
> static void do_thaw_all_callback(struct super_block *sb)
> {
> - down_write(&sb->s_umount);
> - if (sb->s_root && sb->s_flags & SB_BORN) {
> + bool born = super_lock_excl(sb);
> +
> + if (born && sb->s_root) {
> emergency_thaw_bdev(sb);
> - thaw_super_locked(sb);
> + thaw_super_locked(sb, FREEZE_HOLDER_USERSPACE);
> } else {
> - up_write(&sb->s_umount);
> + super_unlock_excl(sb);
> }
> }
>
> @@@ -1644,24 -1836,6 +1836,24 @@@ static void sb_freeze_unlock(struct sup
> percpu_up_write(sb->s_writers.rw_sem + level);
> }
>
> +static int wait_for_partially_frozen(struct super_block *sb)
> +{
> + int ret = 0;
> +
> + do {
> + unsigned short old = sb->s_writers.frozen;
> +
> - up_write(&sb->s_umount);
> ++ super_unlock_excl(sb);
> + ret = wait_var_event_killable(&sb->s_writers.frozen,
> + sb->s_writers.frozen != old);
> - down_write(&sb->s_umount);
> ++ __super_lock_excl(sb);
> + } while (ret == 0 &&
> + sb->s_writers.frozen != SB_UNFROZEN &&
> + sb->s_writers.frozen != SB_FREEZE_COMPLETE);
> +
> + return ret;
> +}
> +
> /**
> * freeze_super - lock the filesystem and force it into a consistent state
> * @sb: the super to lock
> @@@ -1711,34 -1874,10 +1903,34 @@@ int freeze_super(struct super_block *sb
> int ret;
>
> atomic_inc(&sb->s_active);
> - down_write(&sb->s_umount);
> + __super_lock_excl(sb);
> +
> +retry:
> + if (sb->s_writers.frozen == SB_FREEZE_COMPLETE) {
> + if (sb->s_writers.freeze_holders & who) {
> + deactivate_locked_super(sb);
> + return -EBUSY;
> + }
> +
> + WARN_ON(sb->s_writers.freeze_holders == 0);
> +
> + /*
> + * Someone else already holds this type of freeze; share the
> + * freeze and assign the active ref to the freeze.
> + */
> + sb->s_writers.freeze_holders |= who;
> - up_write(&sb->s_umount);
> ++ super_unlock_excl(sb);
> + return 0;
> + }
> +
> if (sb->s_writers.frozen != SB_UNFROZEN) {
> - deactivate_locked_super(sb);
> - return -EBUSY;
> + ret = wait_for_partially_frozen(sb);
> + if (ret) {
> + deactivate_locked_super(sb);
> + return ret;
> + }
> +
> + goto retry;
> }
>
> if (!(sb->s_flags & SB_BORN)) {
> @@@ -1748,10 -1887,8 +1940,10 @@@
>
> if (sb_rdonly(sb)) {
> /* Nothing to do really... */
> + sb->s_writers.freeze_holders |= who;
> sb->s_writers.frozen = SB_FREEZE_COMPLETE;
> + wake_up_var(&sb->s_writers.frozen);
> - up_write(&sb->s_umount);
> + super_unlock_excl(sb);
> return 0;
> }
>
> @@@ -1795,11 -1930,9 +1987,11 @@@
> * For debugging purposes so that fs can warn if it sees write activity
> * when frozen is set to SB_FREEZE_COMPLETE, and for thaw_super().
> */
> + sb->s_writers.freeze_holders |= who;
> sb->s_writers.frozen = SB_FREEZE_COMPLETE;
> + wake_up_var(&sb->s_writers.frozen);
> lockdep_sb_freeze_release(sb);
> - up_write(&sb->s_umount);
> + super_unlock_excl(sb);
> return 0;
> }
> EXPORT_SYMBOL(freeze_super);
> @@@ -1814,24 -1941,8 +2006,24 @@@ static int thaw_super_locked(struct sup
> {
> int error;
>
> - if (sb->s_writers.frozen != SB_FREEZE_COMPLETE) {
> + if (sb->s_writers.frozen == SB_FREEZE_COMPLETE) {
> + if (!(sb->s_writers.freeze_holders & who)) {
> - up_write(&sb->s_umount);
> ++ super_unlock_excl(sb);
> + return -EINVAL;
> + }
> +
> + /*
> + * Freeze is shared with someone else. Release our hold and
> + * drop the active ref that freeze_super assigned to the
> + * freezer.
> + */
> + if (sb->s_writers.freeze_holders & ~who) {
> + sb->s_writers.freeze_holders &= ~who;
> + deactivate_locked_super(sb);
> + return 0;
> + }
> + } else {
> - up_write(&sb->s_umount);
> + super_unlock_excl(sb);
> return -EINVAL;
> }
>
> @@@ -1867,19 -1974,13 +2059,19 @@@ out
> /**
> * thaw_super -- unlock filesystem
> * @sb: the super to thaw
> + * @who: context that wants to freeze
> *
> - * Unlocks the filesystem and marks it writeable again after freeze_super().
> + * Unlocks the filesystem and marks it writeable again after freeze_super()
> + * if there are no remaining freezes on the filesystem.
> + *
> + * @who should be:
> + * * %FREEZE_HOLDER_USERSPACE if userspace wants to thaw the fs;
> + * * %FREEZE_HOLDER_KERNEL if the kernel wants to thaw the fs.
> */
> -int thaw_super(struct super_block *sb)
> +int thaw_super(struct super_block *sb, enum freeze_holder who)
> {
> - down_write(&sb->s_umount);
> + __super_lock_excl(sb);
> - return thaw_super_locked(sb);
> + return thaw_super_locked(sb, who);
> }
> EXPORT_SYMBOL(thaw_super);
>
next prev parent reply other threads:[~2023-08-22 2:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 1:05 linux-next: manual merge of the vfs-brauner tree with the djw-vfs tree Stephen Rothwell
2023-08-22 2:51 ` Darrick J. Wong [this message]
2023-08-22 9:46 ` Christian Brauner
2023-08-22 18:26 ` Darrick J. Wong
2023-08-22 20:19 ` Christian Brauner
2023-08-22 21:14 ` Darrick J. Wong
2023-08-23 7:44 ` Christian Brauner
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=20230822025120.GA11286@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.