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

[Arvind Sankar <nivedita@alum.mit.edu>]

On Fri, Sep 18, 2020 at 06:28:30PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 3:40 PM Arvind Sankar <nivedita@alum.mit.edu> wrote:
> >
> > Ouch, offsetof() and sizeof() will give different results in the
> > presence of alignment padding.
> 
> Indeed. But from an allocation standpoint, the offsetof()+size is I
> think the correct size. The padding at the end makes very little sense
> for something like "struct_size()".

I just meant that my suggestion doesn't actually work to assert that you
passed in the flexible array member to struct_size(), even outside of
any future warnings on sizeof().

And that it's another source of subtle bugs, although you'll err towards
over-allocating memory rather than under-allocating by using sizeof().

Is it ever necessary to allocate _at least_ sizeof() even if
offsetof()+size is smaller?

> 
> Padding at the end is required for sizeof() for a very simple reason:
> arrays.  The "sizeof()" needs to be aligned to the alignment of the
> entry, because if it isn't, then the standard C array traversal
> doesn't work.
> 
> But you cannot sanely have arrays of these structures of variable size
> entries either - even if standard C cheerfully allows you to declare
> them (again: it will not behave like a variable sized array, it will
> behave like a zero-sized one).

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