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

[Linus Torvalds <torvalds@linux-foundation.org>]

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

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

That was in fact one of the test-cases that I submitted to the sparse
list - the insanity of allowing arrays of structures that have a
flexible array at the end is just the C standard being confused. The C
standard may allow it, but I don't think we should allow it in the
kernel.

Oh, I can see why somebody would want to have an array of those things
- exactly because they want to have some "initializer _without_ the
flexible array part", and they actually don't want that variably-sized
array at all for that case.

But I'm pretty sure we really really don't want that kind of oddities
in the kernel. If we really want a separate "struct head_struct", then
I think we should do so explicitly, and have something like

    struct real_struct {
        // Unnamed head struct here
        struct head_struct {
                    ,,,,
        };
        unsigned int variable_array[];
    };

and if you want the part without the flexible array at the end, then
you use that "struct head_struct".

Instead of depending on the imho broken model of the C standard that
says "in lots of cases, we'll just silently make that flexible array
be a zero-sized one".

            Linus