lkml.org 
[lkml]   [2020]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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.)

\
 
 \ /
  Last update: 2020-09-19 04:54    [W:0.062 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site