Re: [PATCH] media: mali-c55: add padding to mali_c55_params_ccm structure

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Sep 16, 2026, at 17:43, Vincenzo Frascino wrote:
>> diff --git a/include/uapi/linux/media/arm/mali-c55-config.h b/include/uapi/linux/media/arm/mali-c55-config.h
>> index 84d8f3901405..9c922290e035 100644
>> --- a/include/uapi/linux/media/arm/mali-c55-config.h
>> +++ b/include/uapi/linux/media/arm/mali-c55-config.h
>> @@ -804,6 +804,7 @@ struct mali_c55_params_ccm {
>>  	__u16 coeffs[3][3];
>>  	__u16 gains[3];
>>  	__u16 offs[3];
>> +	__u16 __pad;
>
> Does this field need to be explicitly zeroed/validated anywhere the structure is
> populated? Turning implicit padding into a named member fixes the layout
> warning, but by itself does not seem to prevent leaking uninitialized data if
> this structure is ever copied from the kernel to userspace. It might also be
> worth documenting that __pad is reserved and must be zero.

It depends on how the structure is initialized. Depending on the compiler
version and optimization level, a local variable declared as

   struct mali_c55_params_ccm v = {};

may end up with uninitialized stack data in unnamed padding, but if you
do a memset(), that should always be safe. If the fields are set individually,
then you also have to set the __pad field, but that's not how you do it here.

> I think you already checked that changing the explicit structure layout/size is
> safe for existing userspace :)

On all architectures other than m68k, the position of the struct members
and the struct size are unchanged by my patch. On m68k. there is no
implied padding at the end of this structure, so this is theoretically
an ABI change, but nobody has a mali device on m68k, so we know that it
is safe.

      Arnd