public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	mcgrof@kernel.org, hch@infradead.org, david@fromorbit.com,
	rafael@kernel.org, djwong@kernel.org, pavel@kernel.org,
	peterz@infradead.org, mingo@redhat.com, will@kernel.org,
	boqun.feng@gmail.com
Subject: [PATCH] fs: allow nesting with FREEZE_EXCL
Date: Fri,  4 Apr 2025 12:24:09 +0200	[thread overview]
Message-ID: <20250404-work-freeze-v1-1-31f9a26f7bc9@kernel.org> (raw)
In-Reply-To: <ilwyxf34ixfkhbylev6d76tz5ufzg2sdxxhy6i3tr4ko5dbefr@57yuviqrftzr>

If hibernation races with filesystem freezing (e.g. DM reconfiguration),
then hibernation need not freeze a filesystem because it's already
frozen but userspace may thaw the filesystem before hibernation actually
happens.

If the race happens the other way around, DM reconfiguration may
unexpectedly fail with EBUSY.

So allow FREEZE_EXCL to nest with other holders. An exclusive freezer
cannot be undone by any of the other concurrent freezers.

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 fs/super.c         | 71 ++++++++++++++++++++++++++++++++++++++++++------------
 include/linux/fs.h |  2 +-
 2 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index b4bdbc509dba..e2fee655fbed 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1979,26 +1979,34 @@ static inline int freeze_dec(struct super_block *sb, enum freeze_holder who)
 	return sb->s_writers.freeze_kcount + sb->s_writers.freeze_ucount;
 }
 
-static inline bool may_freeze(struct super_block *sb, enum freeze_holder who)
+static inline bool may_freeze(struct super_block *sb, enum freeze_holder who,
+			      const void *freeze_owner)
 {
+	lockdep_assert_held(&sb->s_umount);
+
 	WARN_ON_ONCE((who & ~FREEZE_FLAGS));
 	WARN_ON_ONCE(hweight32(who & FREEZE_HOLDERS) > 1);
 
 	if (who & FREEZE_EXCL) {
 		if (WARN_ON_ONCE(!(who & FREEZE_HOLDER_KERNEL)))
 			return false;
-
-		if (who & ~(FREEZE_EXCL | FREEZE_HOLDER_KERNEL))
+		if (WARN_ON_ONCE(who & ~(FREEZE_EXCL | FREEZE_HOLDER_KERNEL)))
 			return false;
-
-		return (sb->s_writers.freeze_kcount +
-			sb->s_writers.freeze_ucount) == 0;
+		if (WARN_ON_ONCE(!freeze_owner))
+			return false;
+		/* This freeze already has a specific owner. */
+		if (sb->s_writers.freeze_owner)
+			return false;
+		/*
+		 * This is already frozen multiple times so we're just
+		 * going to take a reference count and mark it as
+		 * belonging to use.
+		 */
+		if (sb->s_writers.freeze_kcount + sb->s_writers.freeze_ucount)
+			sb->s_writers.freeze_owner = freeze_owner;
+		return true;
 	}
 
-	/* This filesystem is already exclusively frozen. */
-	if (sb->s_writers.freeze_owner)
-		return false;
-
 	if (who & FREEZE_HOLDER_KERNEL)
 		return (who & FREEZE_MAY_NEST) ||
 		       sb->s_writers.freeze_kcount == 0;
@@ -2011,20 +2019,51 @@ static inline bool may_freeze(struct super_block *sb, enum freeze_holder who)
 static inline bool may_unfreeze(struct super_block *sb, enum freeze_holder who,
 				const void *freeze_owner)
 {
+	lockdep_assert_held(&sb->s_umount);
+
 	WARN_ON_ONCE((who & ~FREEZE_FLAGS));
 	WARN_ON_ONCE(hweight32(who & FREEZE_HOLDERS) > 1);
 
 	if (who & FREEZE_EXCL) {
-		if (WARN_ON_ONCE(sb->s_writers.freeze_owner == NULL))
-			return false;
 		if (WARN_ON_ONCE(!(who & FREEZE_HOLDER_KERNEL)))
 			return false;
-		if (who & ~(FREEZE_EXCL | FREEZE_HOLDER_KERNEL))
+		if (WARN_ON_ONCE(who & ~(FREEZE_EXCL | FREEZE_HOLDER_KERNEL)))
+			return false;
+		if (WARN_ON_ONCE(!freeze_owner))
+			return false;
+		if (WARN_ON_ONCE(sb->s_writers.freeze_kcount == 0))
 			return false;
-		return sb->s_writers.freeze_owner == freeze_owner;
+		/* This isn't exclusively frozen. */
+		if (!sb->s_writers.freeze_owner)
+			return false;
+		/* This isn't exclusively frozen by us. */
+		if (sb->s_writers.freeze_owner != freeze_owner)
+			return false;
+		/*
+		 * This is still frozen multiple times so we're just
+		 * going to drop our reference count and undo our
+		 * exclusive freeze.
+		 */
+		if ((sb->s_writers.freeze_kcount + sb->s_writers.freeze_ucount) > 1)
+			sb->s_writers.freeze_owner = NULL;
+		return true;
+	}
+
+	if (who & FREEZE_HOLDER_KERNEL) {
+		/*
+		 * Someone's trying to steal the reference belonging to
+		 * @sb->s_writers.freeze_owner.
+		 */
+		if (sb->s_writers.freeze_kcount == 1 &&
+		    sb->s_writers.freeze_owner)
+			return false;
+		return sb->s_writers.freeze_kcount > 0;
 	}
 
-	return sb->s_writers.freeze_owner == NULL;
+	if (who & FREEZE_HOLDER_USERSPACE)
+		return sb->s_writers.freeze_ucount > 0;
+
+	return false;
 }
 
 /**
@@ -2095,7 +2134,7 @@ int freeze_super(struct super_block *sb, enum freeze_holder who, const void *fre
 
 retry:
 	if (sb->s_writers.frozen == SB_FREEZE_COMPLETE) {
-		if (may_freeze(sb, who))
+		if (may_freeze(sb, who, freeze_owner))
 			ret = !!WARN_ON_ONCE(freeze_inc(sb, who) == 1);
 		else
 			ret = -EBUSY;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1edcba3cd68e..7a3f821d2723 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2270,7 +2270,7 @@ extern loff_t vfs_dedupe_file_range_one(struct file *src_file, loff_t src_pos,
  * @FREEZE_HOLDER_KERNEL: kernel wants to freeze or thaw filesystem
  * @FREEZE_HOLDER_USERSPACE: userspace wants to freeze or thaw filesystem
  * @FREEZE_MAY_NEST: whether nesting freeze and thaw requests is allowed
- * @FREEZE_EXCL: whether actual freezing must be done by the caller
+ * @FREEZE_EXCL: a freeze that can only be undone by the owner
  *
  * Indicate who the owner of the freeze or thaw request is and whether
  * the freeze needs to be exclusive or can nest.

---
base-commit: a83fe97e0d53f7d2b0fc62fd9a322a963cb30306
change-id: 20250404-work-freeze-5eacb515f044


  parent reply	other threads:[~2025-04-04 10:24 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250329-work-freeze-v2-0-a47af37ecc3d@kernel.org>
2025-03-31 12:42 ` [PATCH 0/2] efivarfs: support freeze/thaw Christian Brauner
2025-03-31 12:42   ` [PATCH 1/2] libfs: export find_next_child() Christian Brauner
2025-03-31 12:42   ` [PATCH 2/2] efivarfs: support freeze/thaw Christian Brauner
2025-03-31 14:46     ` James Bottomley
2025-03-31 15:03       ` Christian Brauner
2025-04-01 19:31     ` James Bottomley
2025-04-02  7:44       ` Christian Brauner
2025-03-31 14:05   ` [PATCH 0/2] " Ard Biesheuvel
2025-04-01  0:32   ` [PATCH 0/6] power: wire-up filesystem freeze/thaw with suspend/resume Christian Brauner
2025-04-01  0:32     ` [PATCH 1/6] ext4: replace kthread freezing with auto fs freezing Christian Brauner
2025-04-01  9:16       ` Jan Kara
2025-04-01  9:35         ` Christian Brauner
2025-04-01 10:08           ` Jan Kara
2025-04-01  0:32     ` [PATCH 2/6] btrfs: " Christian Brauner
2025-04-01  0:32     ` [PATCH 3/6] xfs: " Christian Brauner
2025-04-01  1:11       ` Dave Chinner
2025-04-01  7:17         ` Christian Brauner
2025-04-01 11:35           ` Dave Chinner
2025-04-01 12:45             ` Christian Brauner
2025-04-01  0:32     ` [PATCH 4/6] fs: add owner of freeze/thaw Christian Brauner
2025-04-01  0:32     ` [PATCH 5/6] fs: allow pagefault based writers to be frozen Christian Brauner
2025-04-01  0:32     ` [PATCH 6/6] power: freeze filesystems during suspend/resume Christian Brauner
2025-04-01  8:16     ` [PATCH 0/6] power: wire-up filesystem freeze/thaw with suspend/resume Christian Brauner
2025-04-01  9:32     ` Jan Kara
2025-04-01 13:03       ` Christian Brauner
2025-04-01 16:57         ` Jan Kara
2025-04-02 14:07           ` [PATCH v2 0/4] " Christian Brauner
2025-04-02 14:07             ` [PATCH v2 1/4] fs: add owner of freeze/thaw Christian Brauner
2025-04-03 14:56               ` Jan Kara
2025-04-03 19:33                 ` Christian Brauner
2025-04-04 10:24                 ` Christian Brauner [this message]
2025-04-07  9:08                   ` [PATCH] fs: allow nesting with FREEZE_EXCL Christoph Hellwig
2025-05-07 11:18                   ` Jan Kara
2025-05-09 10:38                     ` Christian Brauner
2025-04-02 14:07             ` [PATCH v2 2/4] fs: allow all writers to be frozen Christian Brauner
2025-04-02 15:32               ` Christian Brauner
2025-04-02 16:03                 ` James Bottomley
2025-04-02 16:13                   ` Christian Brauner
2025-04-03 14:59               ` Jan Kara
2025-04-02 14:07             ` [PATCH v2 3/4] power: freeze filesystems during suspend/resume Christian Brauner
2025-04-03 16:29               ` Jan Kara
2025-04-02 14:07             ` [PATCH v2 4/4] kernfs: add warning about implementing freeze/thaw Christian Brauner
2025-04-03 15:00               ` Jan Kara
2025-07-20 19:23             ` [PATCH v2 0/4] power: wire-up filesystem freeze/thaw with suspend/resume Askar Safin
2025-07-21 12:09               ` Jan Kara
2025-08-04  5:31                 ` Miklos Szeredi
2025-08-04  6:02                   ` Askar Safin
2025-08-04  6:51                     ` Sergey Senozhatsky
2025-04-01 14:14     ` [PATCH 0/6] " Peter Zijlstra
2025-04-01 14:40       ` Christian Brauner
2025-04-01 14:59         ` Peter Zijlstra
2025-04-01 17:02     ` James Bottomley
2025-04-02  7:46       ` Christian Brauner
2025-04-08 15:43         ` James Bottomley
2025-04-08 17:09           ` Luis Chamberlain
2025-04-08 17:20             ` Luis Chamberlain
2025-04-08 17:26               ` James Bottomley
2025-04-08 17:24             ` James Bottomley
2025-04-09  7:17           ` 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=20250404-work-freeze-v1-1-31f9a26f7bc9@kernel.org \
    --to=brauner@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=will@kernel.org \
    /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