Re: [GIT PULL] percpu fix for v5.9-rc6

From: Linus Torvalds
Date: Fri Sep 18 2020 - 23:04:30 EST

On Fri, Sep 18, 2020 at 7:53 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> Is it ever necessary to allocate _at least_ sizeof() even if
> offsetof()+size is smaller?

Not that I can tell.

Obviously all allocators tend to have their own alignment concerns, so
they'll all align things up internally anyway.

But why would the alignment of the earlier members of the structure
have anything to do with the size of it? That's nonsensical outside of
the array situation, I feel.

Of course, maybe somebody has such a case: an "array of structures,
each with the same size of flexible array member". And then you _do_
want to align all those entries.

But honestly, once you start doing things like that, why would you
only have one single structure type, much less just one single size of
that flexible array? If you lay out these variably-sized things in
memory each after each other, maybe you lay out multiple different
_kinds_ of variably sized structures?

So there are lots of reasons to want alignment at the end, but why
would the alignment be the same as the beginning of that particular

That said, in the kernel, this probably practically never really
matters. Because typically, our allocation alignment tends to be
bigger than any individual structure type alignment anyway.

So it's probably all moot. The difference between using "sizeof()" and
"offsetof()" is in the noise and not important per se.

No, the real reason I would advocate using 'offsetof()' is really just
that I'd rather have 'sizeof()' cause a warning.

> I think you can't do this in standard C. It's a GCC extension.
> A structure containing a flexible array member, or a union
> containing such a structure (possibly recursively), may not be a
> member of a structure or an element of an array. (However, these
> uses are permitted by GCC as extensions.)


But I'm pretty sure the 'sizeof()' thing is actually the standard, not gcc.

Arrays of those things is odd, and apparently the standard got that
right. Good (but I think it also means that allowing sizeof() makes
even less sense).