From: Michael Kelley <mhklinux@xxxxxxxxxxx> Sent: Sunday, April 27, 2025 8:22 AM
>
> From: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx> Sent: Friday, April 25, 2025 9:48
> AM
> >
> > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> > getting ready to enable it, globally.
> >
> > Use the `DEFINE_RAW_FLEX()` helper for a few on-stack definitions
> > of a flexible structure where the size of the flexible-array member
> > is known at compile-time, and refactor the rest of the code,
> > accordingly.
> >
> > So, with these changes, fix the following warnings:
> >
> > drivers/pci/controller/pci-hyperv.c:3809:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:2831:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:2468:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:1830:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:1593:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:1504:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > drivers/pci/controller/pci-hyperv.c:1424:35: warning: structure containing a flexible
> > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>
> I'm supportive of cleaning up these warnings. I've worked with the pci-hyperv.c
> code a fair amount over the years, but never had looked closely at the on-stack
> structs that are causing the warnings. The current code is a bit unusual and
> perhaps unnecessarily obtuse.
>
> Rather than the approach you've taken below, I tried removing the flex array
> entirely from struct pci_packet. In all cases except one, it was used only to
> locate the end of struct pci_packet, which is the beginning of the follow-on
> message. Locating that follow-on message can easily be done by just referencing
> the "buf" field in the on-stack structs, or as (pkt + 1) in the dynamically allocated
> case. In both cases, there's no need for the flex array. In the one exception, a
> couple of minor tweaks avoids the need for the flex array as well.
>
> So here's an alternate approach to solving the problem. This approach is
> 14 insertions and 15 deletions, so it's a lot less change than your approach.
> I still don't understand why the on-stack struct are declared as (for example):
>
> struct {
> struct pci_packet pkt;
> char buf[sizeof(struct pci_read_block)];
> } pkt;
>
> instead of just:
>
> struct {
> struct pci_packet pkt;
> struct pci_read_block msg;
> } pkt;
>
> but that's a topic for another time. Anyway, here's my proposed diff, which I've
> compiled and smoke-tested in a VM in the Azure cloud:
>
Gustavo -- Are you waiting for me to submit a patch with my alternate proposal?
I had not seen any follow up, so wanted to make sure we have clarity on who
has the next action. Thx.
Michael
