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
