From: Kees Cook <keescook@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Xiu Jianfeng <xiujianfeng@huawei.com>,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
gustavoars@kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH -next, v2] sched: Use struct_size() helper in task_numa_group()
Date: Wed, 19 Jan 2022 11:01:36 -0800 [thread overview]
Message-ID: <202201191057.FAEAF1F94@keescook> (raw)
In-Reply-To: <YeaBCYiTM/mxtBDU@hirez.programming.kicks-ass.net>
On Tue, Jan 18, 2022 at 09:57:45AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 14, 2022 at 07:50:47PM -0800, Kees Cook wrote:
> > On Thu, Jan 13, 2022 at 10:18:57AM +0100, Peter Zijlstra wrote:
>
> > > 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
> >
> > I'm not sure it's _obscure_, but it is relatively new. It's even
> > documented. ;)
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
>
> I'm one of those people who doesn't read documentation, I read code.
>
> I also flat out refuse to read any documentation that isn't plain text.
Sure, which is why it's in the tree:
Documentation/process/deprecated.rst
>
> > > I can't, nor do I want to, remember all these stupid little macros. Esp.
> > > not for trivial things like this.
> >
> > Well, the good news is that other folks will (and are) fixing them for
> > you. :) Even if you never make mistakes with flexible arrays, other
> > people do, and so we need to take on some improvements to the robustness
> > of the kernel source tree-wide.
>
> But nobody helps me read the code when I trip over crap like this :/ Why
> do we have to have endless silly helpers for things that can be
> trivially expressed in regular C? I appreciate things like
> container_of() because if you write that out it's a mess, but this, very
> much not so.
>
> struct_size(grp, faults, NR_NUMA_HINT_FAULTS_STATS * numa_node_ids);
>
> vs
>
> sizeof(*gfp) + sizeof(grp->faults) * NR_NUMA_HINT_FAULT_STATS * nr_node_ids;
>
> The latter wins hands down, instantly obvious what it does while with
> the former I'd have to look up the macro.
One of the drivers is general robustness. The open-coded version can
have bugs slowly drift in, especially with the sizeof() ends up naming
a structs like:
sizeof(struct object) + sizeof(struct element) * NR_NUMA_HINT_FAULT_STATS * nr_node_ids;
One of the points of struct_size() is to include the semantic sanity
checking that the compiler can do (i.e. making sure "faults" is a member
of "grp", correctly sizing them both, avoiding overflows, etc, etc).
I know what you mean about not liking looking up new macros, but given
C's fragility in these areas, it's been important for us to swap stuff
out shift the burdens to the compiler as much as possible.
-Kees
--
Kees Cook
prev parent reply other threads:[~2022-01-19 19:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 1:23 [PATCH -next, v2] sched: Use struct_size() helper in task_numa_group() Xiu Jianfeng
2022-01-10 15:14 ` Steven Rostedt
2022-01-10 22:46 ` Peter Zijlstra
2022-01-11 0:31 ` Steven Rostedt
2022-01-11 6:17 ` Gustavo A. R. Silva
2022-01-11 11:30 ` Peter Zijlstra
2022-01-11 15:14 ` Steven Rostedt
2022-01-13 9:18 ` Peter Zijlstra
2022-01-15 3:50 ` Kees Cook
2022-01-18 1:36 ` xiujianfeng
2022-01-18 8:57 ` Peter Zijlstra
2022-01-19 19:01 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202201191057.FAEAF1F94@keescook \
--to=keescook@chromium.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gustavoars@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=xiujianfeng@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox