On Fri, Mar 01, 2024 at 12:40:57PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally.
>
> There are currently a couple of objects in `struct smc_clc_msg_proposal_area`
> that contain a couple of flexible structures:
>
> struct smc_clc_msg_proposal_area {
> ...
> struct smc_clc_v2_extension pclc_v2_ext;
> ...
> struct smc_clc_smcd_v2_extension pclc_smcd_v2_ext;
> ...
> };
>
> So, in order to avoid ending up with a couple of flexible-array members
> in the middle of a struct, we use the `struct_group_tagged()` helper to
> separate the flexible array from the rest of the members in the flexible
> structure:
>
> struct smc_clc_smcd_v2_extension {
> struct_group_tagged(smc_clc_smcd_v2_extension_hdr, hdr,
> u8 system_eid[SMC_MAX_EID_LEN];
> u8 reserved[16];
> );
> struct smc_clc_smcd_gid_chid gidchid[];
> };
>
> With the change described above, we now declare objects of the type of
> the tagged struct without embedding flexible arrays in the middle of
> another struct:
>
> struct smc_clc_msg_proposal_area {
> ...
> struct smc_clc_v2_extension_hdr pclc_v2_ext;
> ...
> struct smc_clc_smcd_v2_extension_hdr pclc_smcd_v2_ext;
> ...
> };
>
> We also use `container_of()` when we need to retrieve a pointer to the
> flexible structures.
>
> So, with these changes, fix the following warnings:
>
> In file included from net/smc/af_smc.c:42:
> net/smc/smc_clc.h:186:49: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 186 | struct smc_clc_v2_extension pclc_v2_ext;
> | ^~~~~~~~~~~
> net/smc/smc_clc.h:188:49: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 188 | struct smc_clc_smcd_v2_extension pclc_smcd_v2_ext;
> | ^~~~~~~~~~~~~~~~
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx>
I think this is a nice way to deal with these flex-array cases. Using
the struct_group() and container_of() means there is very little
collateral impact. Since this is isolated to a single file, I wonder if
it's easy to check that there are no binary differences too? I wouldn't
expect any -- container_of() is all constant expressions, so the
assignment offsets should all be the same, etc.
Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
-Kees
--
Kees Cook
