>> diff --git a/drivers/infiniband/hw/efa/efa_main.c b/drivers/infiniband/hw/efa/efa_main.c >> index 15ee92081118..1aade398c723 100644 >> --- a/drivers/infiniband/hw/efa/efa_main.c >> +++ b/drivers/infiniband/hw/efa/efa_main.c >> @@ -319,7 +319,9 @@ static int efa_create_eqs(struct efa_dev *dev) >> int err; >> int i; >> >> - neqs = min_t(unsigned int, neqs, num_online_cpus()); >> + neqs = min_t(unsigned int, neqs, >> + dev->num_irq_vectors - EFA_COMP_EQS_VEC_BASE); >> + > If the device supports one msix (which is reserved for commands) you'll > end up with zero neqs, and allocate a zero-sized dev->eqs array. > > Won't that break when efa_create_cq() is called and try to access this > array? > Especially since efa_ib_device_add() sets num_comp_vectors to 1 in such > case.. > >> dev->neqs = neqs; >> dev->eqs = kcalloc(neqs, sizeof(*dev->eqs), GFP_KERNEL); >> if (!dev->eqs) When the number of EQs is 0 we don't report EFA_QUERY_DEVICE_CAPS_CQ_NOTIFICATIONS to the upper layer (rdma-core for example) so it won't be able to request the driver for CQs with interrupts enabled. So in terms of behavior we keep the same behavior as older driver versions. I will need create a separate patch for num_comp_vectors to represent the number of EQs even if its 0 and add driver protection for out of bounds reach to the EQ array. Thanks.
