On Wed, Sep 20, 2017 at 2:26 AM, Leon Romanovsky <leon@xxxxxxxxxx> wrote: > On Tue, Sep 19, 2017 at 02:24:19PM -0400, Jonathan Toppins wrote: >> On 09/19/2017 06:22 AM, Leon Romanovsky wrote: >> > Reduce stack size by dynamically allocating memory instead >> > of declaring large struct on the stack: >> > >> > drivers/infiniband/hw/bnxt_re/ib_verbs.c: In function ‘bnxt_re_query_qp’: >> > drivers/infiniband/hw/bnxt_re/ib_verbs.c:1600:1: warning: the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=] >> > } >> > ^ >> > >> > - memset(&qplib_qp, 0, sizeof(struct bnxt_qplib_qp)); >> > - qplib_qp.id = qp->qplib_qp.id; >> > - qplib_qp.ah.host_sgid_index = qp->qplib_qp.ah.host_sgid_index; >> > + qplib_qp = kzalloc(sizeof(*qplib_qp), GFP_KERNEL); >> ^^^^ >> Can this process block? Further down in the code I see a call to kzalloc >> and they specifically use GFP_ATOMIC. >> >> bnxt_qplib_query_qp() -> >> bnxt_qplib_rcfw_alloc_sbuf() >> >> Looking through the rest of the function and what it calls I am thinking >> this function is assumed to not block so I think GFP_ATOMIC should be >> used here. > > bnxt_re_query_qp() is called as callback of ibdev->query_qp and it is > unlikely that this function will be called in non-blocking context. > > For me, It looks like an error to use GFP_ATOMIC down the call stack. > > P.S. Our mlx4/mlx5 use GFP_KERNEL in query_qp callbacks. > Thanks Leon and Jonathan for your comments. Agree that bnxt_qplib_rcfw_alloc_sbuf implementation can use GFP_KERNEL. GFP_ATOMIC was used because this is a generic function. But none of the current callers of this function are in atomic context. I will post a patch to correct it. Thanks Leon for taking care of this. Acked-by: Selvin Xavier <selvin.xavier@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
