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 PHC | |
Open Source and information security mailing list archives
| ||
|
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.
Powered by blists - more mailing lists