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

[Gustavo A. R. Silva]

On Fri, Sep 18, 2020 at 12:37:48PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 12:28 PM Gustavo A. R. Silva
> <gustavoars@xxxxxxxxxx> wrote:
> >
> > OK. It seems that we are talking about two different things here. One thing
> > is to apply sizeof() to a structure that contains a flexible-array member.
> > And the other thing is to apply sizeof() to a flexible array. The former
> > is allowed, the latter is wrong and we already get a build error when that
> > occurs.
> 
> The latter I'm not even interested in, it's such a pointless thing to do.
> 
> > Applying sizeof() to a structure containing a flex-array member is allowed,
> 
> Yes, and that's wrong and inconsistent, but what else is new about the
> C standard. It's what allows these kinds of bugs to slip through.
> 
> I sent Luc a couple of examples in the hope that maybe sparse could do
> better, but..
> 
> > > Is there some gcc option that I didn't find to help find any questionable cases?
> >
> > If the questionable case is the application of sizeof() to a flex-array
> > member or a flex-array member not occuring last in the containing structure,
> > then yes, GCC already generates a build error for both cases. And that's
> > what we want, see at the bottom...
> 
> No.
> 
> The questionable thing is to do "sizeof(struct-with-flex-array)".

I see now... 

> The point is, it's returning the same thing as if it was just a
> zero-sized array, which makes the whole flex array entirely pointless
> from a type safety standpoint.
> 
> The *only* thing it protects against is the "must be at the end" case,
> which is almost entirely pointless and uninteresting.
> 

But you are missing the point about CONFIG_UBSAN_BOUNDS, which doesn't
work with zero-lenght and one-element arrays. And we want to be able
to use that configuration. That's the main reason why we are replacing
those arrays with a flexible one. I should have made more emphasis on
that point in my last response.

Thanks
--
Gustavo