Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	linux-kbuild@vger.kernel.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: [PATCH 2/2] btrfs: send: make use of -fms-extensions for defining struct fs_path
Date: Mon, 20 Oct 2025 16:22:28 +0200	[thread overview]
Message-ID: <20251020142228.1819871-3-linux@rasmusvillemoes.dk> (raw)
In-Reply-To: <20251020142228.1819871-1-linux@rasmusvillemoes.dk>

The newly introduced -fms-extensions compiler flag allows defining
struct fs_path in such a way that inline_buf becomes a proper array
with a size known to the compiler.

This also makes the problem fixed by 8aec9dbf2db2 ("btrfs: send: fix
-Wflex-array-member-not-at-end warning in struct send_ctx") go
away. Whether cur_inode_path should be put back to its original place
in struct send_ctx I don't know, but at least the comment no longer
applies.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 fs/btrfs/send.c | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6144e66661f5..1fe4a06e6850 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -47,28 +47,30 @@
  * It allows fast adding of path elements on the right side (normal path) and
  * fast adding to the left side (reversed path). A reversed path can also be
  * unreversed if needed.
+ *
+ * The definition of struct fs_path relies on -fms-extensions to allow
+ * including a tagged struct as an anonymous member.
  */
+struct __fs_path {
+	char *start;
+	char *end;
+
+	char *buf;
+	unsigned short buf_len:15;
+	unsigned short reversed:1;
+};
+static_assert(sizeof(struct __fs_path) < 256);
 struct fs_path {
-	union {
-		struct {
-			char *start;
-			char *end;
-
-			char *buf;
-			unsigned short buf_len:15;
-			unsigned short reversed:1;
-			char inline_buf[];
-		};
-		/*
-		 * Average path length does not exceed 200 bytes, we'll have
-		 * better packing in the slab and higher chance to satisfy
-		 * an allocation later during send.
-		 */
-		char pad[256];
-	};
+	struct __fs_path;
+	/*
+	 * Average path length does not exceed 200 bytes, we'll have
+	 * better packing in the slab and higher chance to satisfy
+	 * an allocation later during send.
+	 */
+	char inline_buf[256 - sizeof(struct __fs_path)];
 };
 #define FS_PATH_INLINE_SIZE \
-	(sizeof(struct fs_path) - offsetof(struct fs_path, inline_buf))
+	sizeof_field(struct fs_path, inline_buf)
 
 
 /* reused for each extent */
@@ -305,7 +307,6 @@ struct send_ctx {
 	struct btrfs_lru_cache dir_created_cache;
 	struct btrfs_lru_cache dir_utimes_cache;
 
-	/* Must be last as it ends in a flexible-array member. */
 	struct fs_path cur_inode_path;
 };
 
-- 
2.51.0


  parent reply	other threads:[~2025-10-20 14:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 14:22 [PATCH 0/2] Kbuild: enable -fms-extensions, make btrfs the first user Rasmus Villemoes
2025-10-20 14:22 ` [PATCH 1/2] Kbuild: enable -fms-extensions Rasmus Villemoes
2025-10-22 16:15   ` Nathan Chancellor
2025-10-22 20:35     ` Rasmus Villemoes
2025-10-22 21:11       ` Nathan Chancellor
2025-10-23 12:40         ` Nathan Chancellor
2025-10-23 14:17           ` Dave Kleikamp
2025-10-23 16:45             ` Nathan Chancellor
2025-10-20 14:22 ` Rasmus Villemoes [this message]
2025-10-20 19:48   ` [PATCH 2/2] btrfs: send: make use of -fms-extensions for defining struct fs_path Linus Torvalds
2025-10-22  5:24     ` David Sterba
2025-10-22  5:30 ` [PATCH 0/2] Kbuild: enable -fms-extensions, make btrfs the first user David Sterba
2025-10-22 16:17   ` Nathan Chancellor

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=20251020142228.1819871-3-linux@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=torvalds@linux-foundation.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