From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
To: Kees Cook <kees@kernel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>,
Lyude Paul <lyude@redhat.com>, Danilo Krummrich <dakr@kernel.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH][next] drm/nouveau: chan: Avoid -Wflex-array-member-not-at-end warnings
Date: Mon, 7 Apr 2025 17:35:47 -0600 [thread overview]
Message-ID: <a6dccb66-3f97-443f-85e5-fe089cd93a5e@embeddedor.com> (raw)
In-Reply-To: <202504071336.0C708FCAB8@keescook>
[..]
>>>> - struct {
>>>> - struct nvif_chan_v0 chan;
>>>> - char name[TASK_COMM_LEN+16];
>>>> - } args;
>>>> + DEFINE_RAW_FLEX(struct nvif_chan_v0, args, name, TASK_COMM_LEN + 16);
>>>> struct nvif_device *device = &cli->device;
>>>> struct nouveau_channel *chan;
>>>> const u64 plength = 0x10000;
>>>> @@ -298,28 +295,28 @@ nouveau_channel_ctor(struct nouveau_cli *cli, bool priv, u64 runm,
>>>> return ret;
>>>> /* create channel object */
>>>> - args.chan.version = 0;
>>>> - args.chan.namelen = sizeof(args.name);
>>>> - args.chan.runlist = __ffs64(runm);
>>>> - args.chan.runq = 0;
>>>> - args.chan.priv = priv;
>>>> - args.chan.devm = BIT(0);
>>>> + args->version = 0;
>>>> + args->namelen = __struct_size(args) - sizeof(*args);
>>>
>>> Does __struct_size(args->name) work here (and later)?
>>
>> Why not?
>
> Uhm, I'm genuinely curious. I *think* it will work, but because it's
> within the struct, not outside of it, I'm unclear if it'll DTRT for
> finding the size (since __builtin_object_size() can be touchy).
>
>> I mean, this should be equivalent to `TASK_COMM_LEN+16`, I could
>> use the latter if people prefer it (see my comments below).
>
> Right, it should be the same. I think __struct_size(args->name) would be
> much more readable ... if it works. :)
OK, I'll double check this.
[..]
>>>> @@ -367,17 +365,17 @@ nouveau_channel_init(struct nouveau_channel *chan, u32 vram, u32 gart)
>>>> return ret;
>>>> if (chan->user.oclass >= FERMI_CHANNEL_GPFIFO) {
>>>> - struct {
>>>> - struct nvif_event_v0 base;
>>>> - struct nvif_chan_event_v0 host;
>>>> - } args;
>>>> + DEFINE_RAW_FLEX(struct nvif_event_v0, args, data,
>>>> + sizeof(struct nvif_chan_event_v0));
>>>> + struct nvif_chan_event_v0 *host =
>>>> + (struct nvif_chan_event_v0 *)args->data;
>>>> - args.host.version = 0;
>>>> - args.host.type = NVIF_CHAN_EVENT_V0_KILLED;
>>>> + host->version = 0;
>>>> + host->type = NVIF_CHAN_EVENT_V0_KILLED;
>>>> ret = nvif_event_ctor(&chan->user, "abi16ChanKilled", chan->chid,
>>>> nouveau_channel_killed, false,
>>>> - &args.base, sizeof(args), &chan->kill);
>>>> + args, __struct_size(args), &chan->kill);
>>>> if (ret == 0)
>>>> ret = nvif_event_allow(&chan->kill);
>>>> if (ret) {
>>>> @@ -520,46 +518,45 @@ nouveau_channels_fini(struct nouveau_drm *drm)
>>>> int
>>>> nouveau_channels_init(struct nouveau_drm *drm)
>>>> {
>>>> - struct {
>>>> - struct nv_device_info_v1 m;
>>>> - struct {
>>>> - struct nv_device_info_v1_data channels;
>>>> - struct nv_device_info_v1_data runlists;
>>>> - } v;
>>>> - } args = {
>>>> - .m.version = 1,
>>>> - .m.count = sizeof(args.v) / sizeof(args.v.channels),
>>>
>>> sizeof(args.v) == sizeof(struct nv_device_info_v1_data) * 2
>>>
>>> and sizeof(args.v.channels) == sizeof(struct nv_device_info_v1_data).
>>>
>>> Isn't this just "2"? i.e. isn't struct nv_device_info_v1::count the
>>> counted_by for struct nv_device_info_v1::data?
>>
>> Yes, it's just `2`. However, I didn't want to explicitly use the magic
>> number, in case people don't like it, as in other similar patches (in
>> other subsystems).
>>
>> But, yeah, it's `2`. :)
>
> Okay. So if "count" is set up as a counted_by, the assignment will
> happen automatically (in DEFINE_FLEX -- no longer "RAW").
I really don't want to condition -Wflex-array-member-not-at-end patches
on counted_by patches, for now.
Thanks
--
Gustavo
next prev parent reply other threads:[~2025-04-07 23:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 16:45 [PATCH][next] drm/nouveau: chan: Avoid -Wflex-array-member-not-at-end warnings Gustavo A. R. Silva
2025-04-07 19:50 ` Kees Cook
2025-04-07 19:57 ` Gustavo A. R. Silva
2025-04-07 20:39 ` Kees Cook
2025-04-07 23:35 ` Gustavo A. R. Silva [this message]
2025-04-08 23:40 ` Kees Cook
2025-04-11 7:26 ` Gustavo A. R. Silva
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=a6dccb66-3f97-443f-85e5-fe089cd93a5e@embeddedor.com \
--to=gustavo@embeddedor.com \
--cc=airlied@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=simona@ffwll.ch \
/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