Re: [PATCH 2/2] btrfs: send: make use of -fms-extensions for defining struct fs_path

[David Sterba <dsterba@suse.cz>]

On Mon, Oct 20, 2025 at 09:48:25AM -1000, Linus Torvalds wrote:
> On Mon, 20 Oct 2025 at 04:22, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> >
> > +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 {
> > +       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)];
> >  };
> 
> It strikes me that this won't pack as well as it used to before the change.
> 
> On 64-bit architectrures, 'struct __fs_path' will be 8-byte aligned
> due to the pointers in it, and that means that the size of it will
> also be aligned: it will be 32 bytes in size.
> 
> So you'll get 256-32 bytes of inline_buf.
> 
> And it *used* to be that 'inline_buf[]' was packed righ after the
> 16-bit buf_len / reversed bits, so it used to get an extra six bytes.
> 
> I think it could be fixed with a "__packed" thing on that inner
> struct, but that also worries me a bit because we'd certainly never
> want the compiler to generate the code for unaligned accesses (on the
> broken architectures that would do that). You'd then have to mark the
> containing structure as being aligned to make compilers generate good
> code.
> 
> So either you lose some inline buffer space, or you end up having to
> add extra packing stuff. Either way is a bit of a bother.

For the inline path buffer losing 6 bytes is acceptable, I did some
stats on my system and full paths under /.snapshots from snapper are all
uner 200 bytes, lengths on another random data partition goes up to 380.
Users can of course have path of any length but there's a fallback and
the allocations are done in the steps of slab bucket sizes so it's
reasonably effective.