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

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:

- mpt3sas_config.c:mpt3sas_config_get_number_pds() fetches a
  Mpi2RaidVolPage0_t for itself, but does not use PhysDisk[].

- mpt3sas_config.c:mpt3sas_config_get_raid_volume_pg0() fetches a
  Mpi2RaidVolPage0_t into a caller-provided buffer, and may fetch and
  write PhysDisk[] into that buffer depending on its sz argument.
  Its callers:

  - mpt3sas_scsih.c:scsih_get_resync(),
    mpt3sas_scsih.c:scsih_get_state(),
    mpt3sas_scsih.c:_scsih_search_responding_raid_devices(), and
    mpt3sas_scsih.c:_scsih_scan_for_devices_after_reset() all pass
    sizeof(Mpi2RaidVolPage0_t) as sz, but do not use PhysDisk[].

  - mpt3sas_scsih.c:_scsih_get_volume_capabilities() and
    mpt3sas_warpdrive.c:mpt3sas_init_warpdrive_properties()
    both calculate sz independently of sizeof(Mpi2RaidVolPage0_t)
    and allocate a suitable buffer before calling
    mpt3sas_config_get_raid_volume_pg0() and using PhysDisk[].

Signed-off-by: James Seo <james@equiv.tech>
---
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

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).

> - 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?

> @@ -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);
+	};

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