RE: [PATCH net-next 1/4] net: mana: Fix potential deadlocks in mana napi ops
From: Long Li
Date: Wed Jun 11 2025 - 13:37:18 EST
> Subject: Re: [PATCH net-next 1/4] net: mana: Fix potential deadlocks in mana
> napi ops
>
> On Wed, Jun 11, 2025 at 04:03:52AM -0700, Saurabh Singh Sengar wrote:
> > On Wed, Jun 11, 2025 at 01:46:13AM -0700, Erni Sri Satya Vennela wrote:
> > > When net_shaper_ops are enabled for MANA, netdev_ops_lock becomes
> > > active.
> > >
> > > The netvsc sets up MANA VF via following call chain:
> > >
> > > netvsc_vf_setup()
> > > dev_change_flags()
> > > ...
> > > __dev_open() OR __dev_close()
> > >
> > > dev_change_flags() holds the netdev mutex via netdev_lock_ops.
> > >
> > > During this process, mana_create_txq() and mana_create_rxq() invoke
> > > netif_napi_add_tx(), netif_napi_add_weight(), and napi_enable(), all
> > > of which attempt to acquire the same lock, leading to a potential
> > > deadlock.
> >
> > commit message could be better oriented.
> >
> > >
> > > Similarly, mana_destroy_txq() and mana_destroy_rxq() call
> > > netif_napi_disable() and netif_napi_del(), which also contend for
> > > the same lock.
> > >
> > > Switch to the _locked variants of these APIs to avoid deadlocks when
> > > the netdev_ops_lock is held.
> > >
> > > Fixes: d4c22ec680c8 ("net: hold netdev instance lock during
> > > ndo_open/ndo_stop")
> > > Signed-off-by: Erni Sri Satya Vennela <ernis@xxxxxxxxxxxxxxxxxxx>
> > > Reviewed-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> > > Reviewed-by: Shradha Gupta <shradhagupta@xxxxxxxxxxxxxxxxxxx>
> > > ---
> > > drivers/net/ethernet/microsoft/mana/mana_en.c | 39
> > > ++++++++++++++-----
> > > 1 file changed, 30 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c
> > > b/drivers/net/ethernet/microsoft/mana/mana_en.c
> > > index ccd2885c939e..3c879d8a39e3 100644
> > > --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> > > +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> > > @@ -1911,8 +1911,13 @@ static void mana_destroy_txq(struct
> mana_port_context *apc)
> > > napi = &apc->tx_qp[i].tx_cq.napi;
> > > if (apc->tx_qp[i].txq.napi_initialized) {
> > > napi_synchronize(napi);
> > > - napi_disable(napi);
> > > - netif_napi_del(napi);
> > > + if (netdev_need_ops_lock(napi->dev)) {
> > > + napi_disable_locked(napi);
> > > + netif_napi_del_locked(napi);
> > > + } else {
> > > + napi_disable(napi);
> > > + netif_napi_del(napi);
> > > + }
> >
> > Instead of using if-else, we can used netdev_lock_ops(), followed by *_locked
> api-s.
> > Same for rest of the patch.
> >
>
> I later realized that what we actually need is:
>
> if (!netdev_need_ops_lock(napi->dev))
> netdev_lock(dev);
>
> not
>
> if (netdev_need_ops_lock(napi->dev))
> netdev_lock(dev);
>
> Hence, netdev_lock_ops() is not appropriate. Instead, netdev_lock_ops_to_full()
> seems to be a better choice.
Yes, netdev_lock_ops_to_full() seems better.
Long