Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200918162305.GB25599@embeddedor> <CAHk-=wjH+OH08yjp=LpexkUnGp0Ogusk3WX0G7Q+Lh7Anfr21A@mail.gmail.com>
 <20200918193426.GA15213@embeddedor> <CAHk-=wg=vvSf3M9O1VkwyYB4D4W6XS2AHVpQn6hEQY+usWrKGg@mail.gmail.com>
 <20200918200252.GH32101@casper.infradead.org> <CAHk-=wiNjJGhAMBwYixwkADpNharvcuOG-AMCdii1q_Xo_Ky_A@mail.gmail.com>
 <20200918202909.GA2946008@rani.riverdale.lan> <CAHk-=wh-ryuY7KBNWr1n+kgQ5_CHB3-X+od-djBV4W-1kQFokA@mail.gmail.com>
 <20200918210050.GA2953017@rani.riverdale.lan> <CAHk-=wgyKF9vnac3mw6v-Bo5D8X-rcrkF=BsZ2jX+OveGkGgBw@mail.gmail.com>
 <20200918223957.GA2964553@rani.riverdale.lan>
In-Reply-To: <20200918223957.GA2964553@rani.riverdale.lan>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 18 Sep 2020 18:28:30 -0700
Message-ID: <CAHk-=wg+3Poqh_HQ93nPMWOXLQHZhvYNuwScoQ-WaYWuriLYAg@mail.gmail.com>
Subject: Re: [GIT PULL] percpu fix for v5.9-rc6
To:     Arvind Sankar <nivedita@alum.mit.edu>
Cc:     Matthew Wilcox <willy@infradead.org>,
        "Gustavo A. R. Silva" <gustavoars@kernel.org>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@linux.com>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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