From: Arvind Sankar
> Sent: 18 September 2020 23:40
..
> Ouch, offsetof() and sizeof() will give different results in the
> presence of alignment padding.
>
> https://godbolt.org/z/rqnxTK
>
> I think, grepping at random, that at least struct scsi_vpd is like this,
> size is 24 but data[] starts a
On Sat, Sep 19, 2020 at 03:45:56AM +0100, Matthew Wilcox wrote:
> On Fri, Sep 18, 2020 at 06:39:57PM -0400, Arvind Sankar wrote:
> > On Fri, Sep 18, 2020 at 02:18:20PM -0700, Linus Torvalds wrote:
> > > On Fri, Sep 18, 2020 at 2:00 PM Arvind Sankar
> > > wrote:
> > > >
> > > > You could just asse
On Fri, Sep 18, 2020 at 7:53 PM Arvind Sankar wrote:
>
> Is it ever necessary to allocate _at least_ sizeof() even if
> offsetof()+size is smaller?
Not that I can tell.
Obviously all allocators tend to have their own alignment concerns, so
they'll all align things up internally anyway.
But why
On Fri, Sep 18, 2020 at 10:53:36PM -0400, Arvind Sankar wrote:
> 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 structur
On Fri, Sep 18, 2020 at 06:28:30PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 3:40 PM Arvind Sankar 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
On Fri, Sep 18, 2020 at 06:39:57PM -0400, Arvind Sankar wrote:
> On Fri, Sep 18, 2020 at 02:18:20PM -0700, Linus Torvalds wrote:
> > On Fri, Sep 18, 2020 at 2:00 PM Arvind Sankar wrote:
> > >
> > > You could just assert that offsetof(typeof(s),flex) == sizeof(s), no?
> >
> > No, because the whole
On Fri, Sep 18, 2020 at 3:40 PM Arvind Sankar 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
On Fri, Sep 18, 2020 at 02:18:20PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 2:00 PM Arvind Sankar wrote:
> >
> > You could just assert that offsetof(typeof(s),flex) == sizeof(s), no?
>
> No, because the whole point is that I want that "sizeof(s)" to *WARN*.
>
> It's a nonsensical t
On Fri, Sep 18, 2020 at 2:00 PM Arvind Sankar wrote:
>
> You could just assert that offsetof(typeof(s),flex) == sizeof(s), no?
No, because the whole point is that I want that "sizeof(s)" to *WARN*.
It's a nonsensical thing to do. That 's' has no statically known size.
The C standard is being ve
On Fri, Sep 18, 2020 at 01:40:44PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 1:29 PM Arvind Sankar wrote:
> >
> > In general (i.e. outside the implementation of the macro itself), what
> > is the preferred way of getting the size of just the header?
> > 1) offsetof(typeof(s),flex)
>
On Fri, Sep 18, 2020 at 1:29 PM Arvind Sankar wrote:
>
> In general (i.e. outside the implementation of the macro itself), what
> is the preferred way of getting the size of just the header?
> 1) offsetof(typeof(s),flex)
> 2) struct_size(s, flex, 0)
I think those two should end up being equiv
On Fri, Sep 18, 2020 at 01:14:54PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 1:02 PM Matthew Wilcox wrote:
> >
> > I suppose it's not really necessary, we could do offsetof here, right?
>
> Yup, that would make a lot more sense.
>
> But right now, the sizeof() obviously silently wor
On Fri, Sep 18, 2020 at 1:02 PM Matthew Wilcox wrote:
>
> I suppose it's not really necessary, we could do offsetof here, right?
Yup, that would make a lot more sense.
But right now, the sizeof() obviously silently works.
As do a number of other fairly nonsensical things, like assigning a struc
On Fri, Sep 18, 2020 at 12:37:48PM -0700, Linus Torvalds wrote:
> > 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.
Hmm. We a
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
> 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
On Fri, Sep 18, 2020 at 12:28 PM Gustavo A. R. Silva
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 a
On Fri, Sep 18, 2020 at 10:23:54AM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 9:17 AM Gustavo A. R. Silva
> wrote:
> >
> > This bug could have been prevented by either adopting better
> > coding practices or through the use[3] of the recent struct_size() helper.
>
> Well, my unspoken
On Fri, Sep 18, 2020 at 9:17 AM Gustavo A. R. Silva
wrote:
>
> This bug could have been prevented by either adopting better
> coding practices or through the use[3] of the recent struct_size() helper.
Well, my unspoken point was that coding practices are just
theoretical. Coding practices don't h
On Thu, Sep 17, 2020 at 06:05:13PM -0700, Linus Torvalds wrote:
> On Thu, Sep 17, 2020 at 1:45 PM Dennis Zhou wrote:
> >
> >
> > diff --git a/mm/percpu.c b/mm/percpu.c
> > index f4709629e6de..1ed1a349eab8 100644
> > --- a/mm/percpu.c
> > +++ b/mm/percpu.c
> > @@ -1316,7 +1316,7 @@ static struct pc
The pull request you sent on Thu, 17 Sep 2020 20:45:14 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.9-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/10b82d5176488acee2820e5a2cf0f2ec5c3488b6
Thank you!
--
Deet-doot-dot, I am a
On Thu, Sep 17, 2020 at 1:45 PM Dennis Zhou wrote:
>
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index f4709629e6de..1ed1a349eab8 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1316,7 +1316,7 @@ static struct pcpu_chunk * __init
> pcpu_alloc_first_chunk(unsigned long tmp_addr,
>
>
Hi Linus,
This is a fix for the first chunk size calculation where the variable
length array incorrectly used # of longs instead of bytes of longs. This
came in as a code fix and not a bug report, so I don't think it was
widely problematic. I believe it worked out due to it being memblock
memory a
22 matches
Mail list logo
