On Mon, Mar 08, 2021 at 02:41:29PM -0600, Gustavo A. R. Silva wrote:
> On Mon, Mar 08, 2021 at 12:12:59PM -0800, James Bottomley wrote:
> > On Mon, 2021-03-08 at 13:32 -0600, Gustavo A. R. Silva wrote:
> > > Hi all,
> > >
> > > Friendly ping: who can review/take this, please?
> >
> > Well, before embarking on a huge dynamic update, let's ask Broadcom the
> > simpler question of why isn't MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX simply
> > set to 36? There's no dynamic allocation of anything in the current
> > code ... it's all hard coded to allocate 36 entries. If there's no
> > need for anything dynamic then the kzalloc could become
>
> Yeah; and if that is the case, then there is no even need for kzalloc()
> at all, and it can be replaced by memset():
>
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> index 43a3bf8ff428..d00431f553e1 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> @@ -992,7 +992,7 @@ typedef struct _MPI2_CONFIG_PAGE_IO_UNIT_1 {
> *one and check the value returned for GPIOCount at runtime.
> */
> #ifndef MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX
> -#define MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX (1)
> +#define MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX (36)
> #endif
>
> typedef struct _MPI2_CONFIG_PAGE_IO_UNIT_3 {
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> index 44f9a05db94e..23fcf29bfd67 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
> @@ -3203,7 +3203,7 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> struct MPT3SAS_ADAPTER *ioc = shost_priv(shost);
> - Mpi2IOUnitPage3_t *io_unit_pg3 = NULL;
> + Mpi2IOUnitPage3_t io_unit_pg3;
> Mpi2ConfigReply_t mpi_reply;
> u16 backup_rail_monitor_status = 0;
> u16 ioc_status;
> @@ -3221,16 +3221,10 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
> goto out;
>
> /* allocate upto GPIOVal 36 entries */
> - sz = offsetof(Mpi2IOUnitPage3_t, GPIOVal) + (sizeof(u16) * 36);
> - io_unit_pg3 = kzalloc(sz, GFP_KERNEL);
> - if (!io_unit_pg3) {
> - rc = -ENOMEM;
> - ioc_err(ioc, "%s: failed allocating memory for iounit_pg3: (%d) bytes\n",
> - __func__, sz);
> - goto out;
> - }
> + sz = sizeof(io_unit_pg3);
> + memset(&io_unit_pg3, 0, sz);
I like this a lot. It makes the code way simpler.
Putting this on the stack makes it faster, and it's less than 100 bytes,
which seems entirely reasonable.
>
> - if (mpt3sas_config_get_iounit_pg3(ioc, &mpi_reply, io_unit_pg3, sz) !=
> + if (mpt3sas_config_get_iounit_pg3(ioc, &mpi_reply, &io_unit_pg3, sz) !=
The only thing I can imagine is if this ends up doing DMA, which isn't
allowed on the stack. However, in looking down through the call path,
it's _copied_ into DMA memory, so this appears entirely safe.
Can you send this as a "normal" patch? Feel free to include:
Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
Thanks!
-Kees
> 0) {
> ioc_err(ioc, "%s: failed reading iounit_pg3\n",
> __func__);
> @@ -3246,19 +3240,18 @@ BRM_status_show(struct device *cdev, struct device_attribute *attr,
> goto out;
> }
>
> - if (io_unit_pg3->GPIOCount < 25) {
> - ioc_err(ioc, "%s: iounit_pg3->GPIOCount less than 25 entries, detected (%d) entries\n",
> - __func__, io_unit_pg3->GPIOCount);
> + if (io_unit_pg3.GPIOCount < 25) {
> + ioc_err(ioc, "%s: iounit_pg3.GPIOCount less than 25 entries, detected (%d) entries\n",
> + __func__, io_unit_pg3.GPIOCount);
> rc = -EINVAL;
> goto out;
> }
>
> /* BRM status is in bit zero of GPIOVal[24] */
> - backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]);
> + backup_rail_monitor_status = le16_to_cpu(io_unit_pg3.GPIOVal[24]);
> rc = snprintf(buf, PAGE_SIZE, "%d\n", (backup_rail_monitor_status & 1));
>
> out:
> - kfree(io_unit_pg3);
> mutex_unlock(&ioc->pci_access_mutex);
> return rc;
> }
>
> >
> > io_unit_pg3 = kzalloc(sizeof(*io_unit_pg3), GFP_KERNEL);
> >
>
> Thanks
> --
> Gustavo
--
Kees Cook
