linux-hardening - Re: [PATCH -next, v2] sched: Use struct_size() helper in task_numa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yd/ugQ8kUmcceuex@hirez.programming.kicks-ass.net>
Date:   Thu, 13 Jan 2022 10:18:57 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Xiu Jianfeng <xiujianfeng@...wei.com>, mingo@...hat.com,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, gustavoars@...nel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH -next, v2] sched: Use struct_size() helper in
 task_numa_group()

On Tue, Jan 11, 2022 at 10:14:25AM -0500, Steven Rostedt wrote:
> On Tue, 11 Jan 2022 12:30:42 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > > > >  	if (unlikely(!deref_curr_numa_group(p))) {
> > > > > -		unsigned int size = sizeof(struct numa_group) +
> > > > > -				    NR_NUMA_HINT_FAULT_STATS *
> > > > > -				    nr_node_ids * sizeof(unsigned long);
> > > > > +		unsigned int size = struct_size(grp, faults,
> > > > > +						NR_NUMA_HINT_FAULT_STATS * nr_node_ids);    
> > > > 
> > > > Again, why?! The old code was perfectly readable, this, not so much.  
> > > 
> > > Because it is unsafe,  
> > 
> > Unsafe how? Changelog doesn't mention anything, nor do you. In fact,
> > Changelog says there is no functional change, which makes me hate the
> > thing for obscuring something that was simple.
> 
> If for some reason faults changes in size, the original code must be
> updated whereas the new code is robust enough to not need changing.

Then I would still much prefer something like:

	unsigned int size = sizeof(*grp) +
			    NR_NUMA_HINT_FAULT_STATS * numa_node_ids * sizeof(gfp->faults);

Which is still far more readable than some obscure macro. But again, the
Changelog doesn't mention any actual benefit of the patch and makes the
code less clear.

> It's a C hack and far from trivial. Maybe to you as you are use to
> these hacks. But seriously, this is not something the average C coder
> is use to, as variable length structures are rather unique to the
> kernel.

That's just not true, I've used them in userspace too (even before I
started tinkering with the kernel). I've even used this pattern in other
languages.

It is a fairly useful and common pattern to have a small structure and
an array in the same memory allocation.

Think hash-tables, the structure contains the size of the table and some
other things, like for example a seed for the hash function or a lock,
and then the table itself as an array.

I can't, nor do I want to, remember all these stupid little macros. Esp.
not for trivial things like this.