Re: [PATCH net] nfp: flower: avoid taking mutex in atomic context

[Leon Romanovsky <leon@kernel.org>]

On Tue, Jan 31, 2023 at 01:15:46PM +0100, Simon Horman wrote:
> On Tue, Jan 31, 2023 at 01:45:10PM +0200, Leon Romanovsky wrote:
> > On Tue, Jan 31, 2023 at 09:03:13AM +0100, Simon Horman wrote:
> > > From: Yanguo Li <yanguo.li@corigine.com>
> > > 
> > > A mutex may sleep, which is not permitted in atomic context.
> > > Avoid a case where this may arise by moving the to
> > > nfp_flower_lag_get_info_from_netdev() in nfp_tun_write_neigh() spinlock.
> > > 
> > > Fixes: abc210952af7 ("nfp: flower: tunnel neigh support bond offload")
> > > Reported-by: Dan Carpenter <error27@gmail.com>
> > > Signed-off-by: Yanguo Li <yanguo.li@corigine.com>
> > > Signed-off-by: Simon Horman <simon.horman@corigine.com>
> > > ---
> > >  drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
> > > index a8678d5612ee..060a77f2265d 100644
> > > --- a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
> > > +++ b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
> > > @@ -460,6 +460,7 @@ nfp_tun_write_neigh(struct net_device *netdev, struct nfp_app *app,
> > >  			    sizeof(struct nfp_tun_neigh_v4);
> > >  	unsigned long cookie = (unsigned long)neigh;
> > >  	struct nfp_flower_priv *priv = app->priv;
> > > +	struct nfp_tun_neigh_lag lag_info;
> > >  	struct nfp_neigh_entry *nn_entry;
> > >  	u32 port_id;
> > >  	u8 mtype;
> > > @@ -468,6 +469,11 @@ nfp_tun_write_neigh(struct net_device *netdev, struct nfp_app *app,
> > >  	if (!port_id)
> > >  		return;
> > >  
> > > +	if ((port_id & NFP_FL_LAG_OUT) == NFP_FL_LAG_OUT) {
> > > +		memset(&lag_info, 0, sizeof(struct nfp_tun_neigh_lag));
> > 
> > This memset can be removed if you initialize lag_info to zero.
> > struct nfp_tun_neigh_lag lag_info = {};
> 
> Happy to change if that is preferred.
> Is it preferred?

I don't see why it can't be preferred.

Thanks