Messages in this thread | | | From | Arvind Sankar <> | Date | Fri, 18 Sep 2020 22:53:36 -0400 | Subject | Re: [GIT PULL] percpu fix for v5.9-rc6 |
| |
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.)
| |