> > qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
> > invoked in the interrupt context by qed_dcbnl_getdcbx callback. Need
> > to invoke this kmalloc in atomic mode.
> >
> > Signed-off-by: Sudarsana Reddy Kalluru <sudarsana.kall...@cavium.com>
> > Signed-off-by: Yuval Mintz <yuval.mi...@cavium.com>
> > ---
> > drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
> > b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
> > index ff058a3..8f0783a 100644
> > --- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
> > +++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
> > @@ -1264,7 +1264,7 @@ static struct qed_dcbx_get
> > *qed_dcbnl_get_dcbx(struct qed_hwfn *hwfn, {
> > struct qed_dcbx_get *dcbx_info;
> >
> > - dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
> > + dcbx_info = kmalloc(sizeof(*dcbx_info), GFP_ATOMIC);
>
> You are changing a kzalloc to kmalloc, was that intentional?
Not really. Apparently the confusion resulted from the fact that
immediately after the next condition we're memsetting dcbx_info
to zero [so current code zeros the memory twice], which also
means there's no functional problem with this change.
Dave, do you want us to re-spin this [even though change isn't
functionally broken]?
Notice this is a recurrent pattern, so in future we'd have to send
a cleanup for these kind of stuff, regardless of whether we re-spin
now or not.
>
> > if (!dcbx_info)
> > return NULL;
> >
> > --
> > 1.8.3.1
> >
> >
