From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] [next] drm/radeon: Replace one-element array with flexible-array member
Date: Wed, 2 Nov 2022 10:13:54 +1300 [thread overview]
Message-ID: <Y2GMEjB4NQ3RYk2C@mail.google.com> (raw)
In-Reply-To: <CADnq5_Mod90O=tN26+Yi74WPYxpVtss+LG_+_HZyFv2EtzR+MA@mail.gmail.com>
On Tue, Nov 01, 2022 at 10:42:14AM -0400, Alex Deucher wrote:
> On Fri, Oct 28, 2022 at 11:32 PM Paulo Miguel Almeida
> <paulo.miguel.almeida.rodenas@gmail.com> wrote:
> >
> > One-element arrays are deprecated, and we are replacing them with
> > flexible array members instead. So, replace one-element array with
> > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and
> > refactor the rest of the code accordingly.
> >
> > It's worth mentioning that doing a build before/after this patch results
> > in no binary output differences.
> >
> > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> > routines on memcpy() and help us make progress towards globally
> > enabling -fstrict-flex-arrays=3 [1].
>
> This seems like a worthy goal, and I'm not opposed to the patch per
> se, but it seems a bit at odds with what this header represents.
> atombios.h represents the memory layout of the data stored in the ROM
> on the GPU. This changes the memory layout of that ROM. We can work
> around that in the driver code, but if someone were to take this
> header to try and write some standalone tool or use it for something
> else in the kernel, it would not reflect reality.
>
> Alex
>
Hi Alex, thanks for taking the time to review this patch.
I see where you are coming from and why you may be apprehensive with the
approach. From my humble point of view, I think that the artificial line
that separates "what we can change at will" and "what we should be extra
careful not to break/confuse others" is whether the header file is part
of the UAPI. Given that atombios.h isn't publicly accessible, I tend to
gravitate towards the first one.
> > + /* empty fake edid record must be 3 bytes long */
> + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1;
I am assuming that this is the part of the patch that makes you feel
concerned about how devs will get it (should they copy this header),
is that right?
If so, would a comment on the ATOM_FAKE_EDID_PATCH_RECORD struct
specifying the size of the struct when empty do the trick?
- Paulo A.
next prev parent reply other threads:[~2022-11-01 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 5:41 [PATCH] [next] drm/radeon: Replace one-element array with flexible-array member Paulo Miguel Almeida
2022-10-29 3:32 ` [PATCH v2] " Paulo Miguel Almeida
2022-10-29 4:04 ` Kees Cook
2022-11-01 14:42 ` Alex Deucher
2022-11-01 21:13 ` Paulo Miguel Almeida [this message]
2022-11-01 21:27 ` Alex Deucher
2022-11-01 21:54 ` Kees Cook
2022-11-01 22:09 ` Alex Deucher
2022-11-01 22:41 ` Kees Cook
2022-11-02 16:11 ` Alex Deucher
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=Y2GMEjB4NQ3RYk2C@mail.google.com \
--to=paulo.miguel.almeida.rodenas@gmail.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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