Btrfs fixes for 6.18-rc2
David Sterba
maintainerHi,
please pull a bunch of one-liners and short fixes. Thanks.
- in tree-checker fix extref bounds check
- reorder send context structure to avoid -Wflex-array-member-not-at-end warning
- fix extent readahead length for compressed extents
- fix memory leaks on error paths (qgroup assign ioctl, zone loading with raid stripe tree enabled)
- fix how device specific mount options are applied, in particular the 'ssd' option will be set unexpectedly
- fix tracking of relocation state when tasks are running and cancellation is attempted
- adjust assertion condition for folios allocated for scrub
- remove incorrect assertion checking for block group when populating free space tree
----------------------------------------------------------------
The following changes since commit 4335c4496b1bcf8e85761af23550a180e937bac6:
btrfs: fix PAGE_SIZE format specifier in open_ctree() (2025-10-01 16:27:28 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git tags/for-6.18-rc1-tag
for you to fetch changes up to 8aec9dbf2db2e958de5bd20e23b8fbb8f2aa1fa6:
btrfs: send: fix -Wflex-array-member-not-at-end warning in struct send_ctx (2025-10-13 22:36:38 +0200)
----------------------------------------------------------------
Boris Burkov (1):
btrfs: fix incorrect readahead expansion length
Dan Carpenter (1):
btrfs: tree-checker: fix bounds check in check_inode_extref()
Filipe Manana (2):
btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already running
btrfs: do not assert we found block group item when creating free space tree
Gustavo A. R. Silva (1):
btrfs: send: fix -Wflex-array-member-not-at-end warning in struct send_ctx
Miquel Sabaté Solà (2):
btrfs: fix memory leak on duplicated memory in the qgroup assign ioctl
btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST
Qu Wenruo (2):
btrfs: only set the device specific options after devices are opened
btrfs: do not use folio_test_partial_kmap() in ASSERT()s
fs/btrfs/extent_io.c | 2 +- fs/btrfs/free-space-tree.c | 15 ++++++++------- fs/btrfs/ioctl.c | 2 +- fs/btrfs/relocation.c | 13 +++++++------ fs/btrfs/scrub.c | 4 ++-- fs/btrfs/send.c | 4 +++- fs/btrfs/super.c | 3 +-- fs/btrfs/tree-checker.c | 2 +- fs/btrfs/zoned.c | 2 +- 9 files changed, 25 insertions(+), 22 deletions(-)
Quoted 3 lines · David Sterba
- reorder send context structure to avoid -Wflex-array-member-not-at-end warning
Ok, I took a look because this sounded like a bad bug, but that flex array member really isn't a flex array at all.
It's clearly intended to be a fixed-size inline array, just using a flex array for syntacting reasons.
And that not only resulted in that warning, it also means that the compilers can't actually check the *real* size of the array and won't realize if there's some actual overflow problem that they might otherwise have been able to see.
I do see why it's done that way, but it's not wonderful.
I'm trying to think of a way to do this cleanly - we have some similar things elsewhere (like the DNAME_INLINE_LEN for the dentry, which has a similar kind of use-case).
But in the dentry - exactly to avoid using a flex array when it really isn't - we have that ugly "calculate things by hand" (and the whole union shortname_store, so that you can also treat it as an array or words, but that's a separate independent optimization).
Sadly, I can't think of a way to have the compiler just calculate the right size at structure definition time without just having to repeat the whole structure definition twice.
So that flex array may be the best approach even if it has these downsides.
Does anybody know of some C language trick to get the remaining padding size without repeating the struct definition?
"offsetof()" sadly does not work until the structure has been fully defined, so you can't use the "obvious" trick
char buffer[256 - offsetof(struct .., buffer)];
and anonymous structure members not only don't name the container, the strcture type also cannot be named, so you can't do
struct outer {
struct inner {
..
};
char buffer[256 - sizeof(struct inner)];
};to create that buffer.
Oh well.
Linus
Quoted 11 lines · Linus Torvalds
Quoted 3 lines · David Sterba
- reorder send context structure to avoid -Wflex-array-member-not-at-end warning
Ok, I took a look because this sounded like a bad bug, but that flex array member really isn't a flex array at all.
It's clearly intended to be a fixed-size inline array, just using a flex array for syntacting reasons.
[...]
Quoted 7 lines
Sadly, I can't think of a way to have the compiler just calculate the right size at structure definition time without just having to repeat the whole structure definition twice.
So that flex array may be the best approach even if it has these downsides.
Quoted 8 lines
Does anybody know of some C language trick to get the remaining padding size without repeating the struct definition?
"
offsetof()" sadly does not work until the structure has been fully defined, so you can't use the "obvious" trickchar buffer[256 - offsetof(struct .., buffer)];
I think this has come up before [*]. Doesn't -fms-extensions allow one to do
struct __fs_path {
char *start;
char *end;
...
};
static_assert(sizeof(struct __fs_path) < 256);
struct fs_path {
struct __fs_path;
char inline_buf[256 - sizeof(struct __fs_path)];
};and access every member of fs_path as one used to? With the bonus that it's a real array with known size.
Rasmus
[*]
https://lore.kernel.org/lkml/CAHk-=wh6Ra8=dBUTo1vKT5Wao1hFq3+2x1mDwmBcVx2Ahp_rag@mail.gmail.com/
Quoted 3 lines · Rasmus Villemoes
I think this has come up before [*]. Doesn't -fms-extensions allow one to do
I clearly have some goldfish genes, because I had completely forgotten about that whole similar conversation.
Yeah, so now we've had at least two use-cases for that thing, although from that older discussion we'd apparently need both
-fms-extensions
and
-Wno-microsoft-anon-tag
to also make clang happy about it.
But yeah, if all versions of gcc and clang that we support do accept this thing, maybe we should just bite the bullet and do it, because it's just universally useful to be able to define a common helper structure and then use it in other structures without naming it. Kind of standard "inheritance" syntax, and very useful for that "I have two or more parts to this object".
Want to take that up and see if the btrfs people like the end result?
Linus
Quoted 19 lines · Linus Torvalds
Quoted 3 lines · Rasmus Villemoes
I think this has come up before [*]. Doesn't -fms-extensions allow one to do
I clearly have some goldfish genes, because I had completely forgotten about that whole similar conversation.
Yeah, so now we've had at least two use-cases for that thing, although from that older discussion we'd apparently need both
-fms-extensions
and
-Wno-microsoft-anon-tag
to also make clang happy about it.
Quoted 8 lines
But yeah, if all versions of gcc and clang that we support do accept this thing, maybe we should just bite the bullet and do it, because it's just universally useful to be able to define a common helper structure and then use it in other structures without naming it. Kind of standard "inheritance" syntax, and very useful for that "I have two or more parts to this object".
Want to take that up and see if the btrfs people like the end result?
No objections from me. The other effect of enabling the extensions seems to be useful wrt the other references in
https://lore.kernel.org/all/[email protected]/
The pull request you sent on Thu, 16 Oct 2025 18:59:52 +0200:
The pull request you sent on Thu, 16 Oct 2025 18:59:52 +0200:
Quoted 1 line
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.gittags/for-6.18-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9f388a653c8a481cbdbdedca081a1f9f3ba204a2
Thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html