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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wiiysgAErOobR02zECiniaM69AacAHjTOSKsv3yDF2R+A@mail.gmail.com>
Date: Thu, 16 Oct 2025 10:58:16 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Sterba <dsterba@...e.com>
Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 6.18-rc2

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