On Mon, 27 Apr 2026, "Gustavo A. R. Silva" <[email protected]> wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Use the TRAILING_OVERLAP() helper to fix the following warning:
>
> drivers/gpu/drm/i915/gvt/opregion.c:126:40: warning: structure containing a
> flexible array member is not at the end of another structure
> [-Wflex-array-member-not-at-end]
>
> This helper creates a union between a flexible-array member (FAM)
> and a set of members that would otherwise follow it. This overlays
> the trailing members onto the FAM while preserving the original
> memory layout.
>
> Lastly, the static_assert() ensures the alignment between the FAM and
> struct efp_child_device_config child0; is not inadvertently changed,
> and it's intentionally placed inmediately after the related structure
> (that is, no blank line in between).
>
> Signed-off-by: Gustavo A. R. Silva <[email protected]>
> ---
> drivers/gpu/drm/i915/gvt/opregion.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/opregion.c
> b/drivers/gpu/drm/i915/gvt/opregion.c
> index d6e76ba31d60..efe457c02788 100644
> --- a/drivers/gpu/drm/i915/gvt/opregion.c
> +++ b/drivers/gpu/drm/i915/gvt/opregion.c
> @@ -122,17 +122,21 @@ struct vbt {
> struct bdb_data_header general_features_header;
> struct bdb_general_features general_features;
>
> - struct bdb_data_header general_definitions_header;
> - struct bdb_general_definitions general_definitions;
> -
> - struct efp_child_device_config child0;
> - struct efp_child_device_config child1;
> - struct efp_child_device_config child2;
> - struct efp_child_device_config child3;
> -
> struct bdb_data_header driver_features_header;
> struct bdb_driver_features driver_features;
> +
> + struct bdb_data_header general_definitions_header;
> +
> + /* Must be last as it ends in a flexible-array member. */
> + TRAILING_OVERLAP(struct bdb_general_definitions, general_definitions,
> devices,
> + struct efp_child_device_config child0;
> + struct efp_child_device_config child1;
> + struct efp_child_device_config child2;
> + struct efp_child_device_config child3;
> + );
So this impacts the generation of a binary blob, parsed by the client OS
driver. In theory, the order of the BDB blocks shouldn't matter, but who
knows.
Anyway, I'm more worried about inadvertent padding potentially being
introduced. struct vbt should have __packed attribute, which is missing,
but I also think the union and the struct within TRAILING_OVERLAP()
should also have __packed.
Like, if struct efp_child_device_config gets extended by one byte,
what's going to happen with padding? It's __packed on its own, but IIUC
that doesn't automatically apply to the enclosing structs or unions.
> };
> +static_assert(offsetof(struct vbt, general_definitions.devices) ==
> + offsetof(struct vbt, child0));
Perhaps also assert child1 offset is child0 offset + sizeof(struct
efp_child_device_config)? That should cover the padding, right?
BR,
Jani.
>
> static void virt_vbt_generation(struct vbt *v)
> {
--
Jani Nikula, Intel
