[GIT PULL] Btrfs fixes for 6.18-rc2

[GIT PULL] Btrfs fixes for 6.18-rc2

[David Sterba]

Hi,

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

Re: [GIT PULL] Btrfs fixes for 6.18-rc2

[Linus Torvalds]

On Thu, 16 Oct 2025 at 10:00, David Sterba <dsterba@suse.com> wrote:
>
> - 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

Re: [GIT PULL] Btrfs fixes for 6.18-rc2

[pr-tracker-bot]

The pull request you sent on Thu, 16 Oct 2025 18:59:52 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git tags/for-6.18-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9f388a653c8a481cbdbdedca081a1f9f3ba204a2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Btrfs fixes for 6.18-rc2

[Rasmus Villemoes]

On Thu, Oct 16 2025, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 16 Oct 2025 at 10:00, David Sterba <dsterba@suse.com> wrote:
>>
>> - 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.
>
[...]
>
> 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)];
>

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/

Re: [GIT PULL] Btrfs fixes for 6.18-rc2

[Linus Torvalds]

On Sun, 19 Oct 2025 at 11:53, Rasmus Villemoes <ravi@prevas.dk> wrote:
>
> 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

Re: [GIT PULL] Btrfs fixes for 6.18-rc2

[David Sterba]

On Sun, Oct 19, 2025 at 03:17:32PM -1000, Linus Torvalds wrote:
> On Sun, 19 Oct 2025 at 11:53, Rasmus Villemoes <ravi@prevas.dk> wrote:
> >
> > 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?

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/20251020142228.1819871-2-linux@rasmusvillemoes.dk/