Re: [PATCH v2 03/12] scsi: mpt3sas: Make MPI2_CONFIG_PAGE_RAID_VOL_0::PhysDisk[] a flexible array

[James Seo]

On Fri, Aug 25, 2023 at 02:03:23PM -0700, Kees Cook wrote:
> On Sun, Aug 06, 2023 at 10:05:55AM -0700, James Seo wrote:
>> This terminal 1-length variable array can be directly converted into
>> a C99 flexible array member.
>> 
>> As all users of MPI2_CONFIG_PAGE_RAID_VOL_0 (Mpi2RaidVolPage0_t)
>> either calculate its size without depending on its sizeof() or do not
>> use PhysDisk[], no further source changes are required:
> 
> Tons of binary changes in this file too. I see this:
> 
>         Mpi2RaidVolPage0_t config_page;
> 	...
>         r = _config_request(ioc, &mpi_request, &mpi_reply,
>             MPT3_CONFIG_PAGE_DEFAULT_TIMEOUT, &config_page,
>             sizeof(Mpi2RaidVolPage0_t));
> 
> So it's already changing this size (and possibly under-allocating now).

Yes. I didn't explicitly identify _config_request() as a user of the
five structs for which I parted out changes into their own commits,
as it's a generalized helper indirectly called when working with
other config page structs as well. Rest assured that I took it into
account, and that the reduced struct sizes don't represent
under-allocations (see below).

>> - mpt3sas_config.c:mpt3sas_config_get_number_pds() fetches a
>>   Mpi2RaidVolPage0_t for itself, but does not use PhysDisk[].
> 
> Is it certain that _config_request()'s use of mpt3sas_wait_for_ioc()
> won't result in the hardware being upset that config_page_sz shrank?
 
Sorry if I missed it, but I don't see what config_page_sz has to do
with _config_request()'s use of mpt3sas_wait_for_ioc(). Could you
explain what you meant?

More generally, changes in config_page_sz shouldn't faze the hardware
because all usages of _config_request() occur in pairs - a
preparatory call that returns the actual size of a given config page
in mpi_reply, then a follow-up call during which a temporary
DMA-capable buffer is allocated per the size in mpi_reply and the
hardware reads/writes the entirety of this buffer. config_page_sz
just determines the number of bytes copied between config_page and
the temp buffer after a hardware read/before a hardware write.

Well, as far I can tell, anyway. Maybe Broadcom knows otherwise.

>> @@ -1826,8 +1823,7 @@ typedef struct _MPI2_CONFIG_PAGE_RAID_VOL_0 {
>>  	U8                      Reserved2;         /*0x25 */
>>  	U8                      Reserved3;         /*0x26 */
>>  	U8                      InactiveStatus;    /*0x27 */
>> -	MPI2_RAIDVOL0_PHYS_DISK
>> -	PhysDisk[MPI2_RAID_VOL_PAGE_0_PHYSDISK_MAX]; /*0x28 */
>> +	MPI2_RAIDVOL0_PHYS_DISK PhysDisk[];        /*0x28 */
>>  } MPI2_CONFIG_PAGE_RAID_VOL_0,
> 
> Without the mpt3sas maintainers chiming in on this, I think the only
> safe changes to make here are those with 0 binary differences. So for
> things like this, it'll need to be:
> 
> -	MPI2_RAIDVOL0_PHYS_DISK
> -	PhysDisk[MPI2_RAID_VOL_PAGE_0_PHYSDISK_MAX]; /*0x28 */
> +	union {
> +		MPI2_RAIDVOL0_PHYS_DISK legacy_padding;        /*0x28 */
> +		DECLARE_FLEX_ARRAY(MPI2_RAIDVOL0_PHYS_DISK, PhysDisk);
> +	};
> 
> -- 
> Kees Cook

Thanks for clearing that up. Here's hoping those mpt3sas maintainers
do chime in. I'll go with the union workaround if they don't.

James