linux-kernel - RE: [PATCH net-next v2 1/4] net: mana: Fix potential deadlocks in mana napi ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <DS7PR21MB3102F21CA7AE05FFF4CA5563CE77A@DS7PR21MB3102.namprd21.prod.outlook.com>
Date: Fri, 13 Jun 2025 17:01:47 +0000
From: Long Li <longli@...rosoft.com>
To: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>, KY Srinivasan
	<kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	Konstantin Taranov <kotaranov@...rosoft.com>, "horms@...nel.org"
	<horms@...nel.org>, Shiraz Saleem <shirazsaleem@...rosoft.com>,
	"leon@...nel.org" <leon@...nel.org>, "shradhagupta@...ux.microsoft.com"
	<shradhagupta@...ux.microsoft.com>, "schakrabarti@...ux.microsoft.com"
	<schakrabarti@...ux.microsoft.com>, "gerhard@...leder-embedded.com"
	<gerhard@...leder-embedded.com>, "rosenp@...il.com" <rosenp@...il.com>,
	"sdf@...ichev.me" <sdf@...ichev.me>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>
Subject: RE: [PATCH net-next v2 1/4] net: mana: Fix potential deadlocks in
 mana napi ops

> Subject: [PATCH net-next v2 1/4] net: mana: Fix potential deadlocks in mana napi
> ops
> 
> When net_shaper_ops are enabled for MANA, netdev_ops_lock becomes active.
> 
> MANA VF setup/teardown by netvsc follows this call chain:
> 
> netvsc_vf_setup()
>         dev_change_flags()
> 		...
>          __dev_open() OR __dev_close()
> 
> dev_change_flags() holds the netdev mutex via netdev_lock_ops.
> 
> Meanwhile, mana_create_txq() and mana_create_rxq() in mana_open() path call
> NAPI APIs (netif_napi_add_tx(), netif_napi_add_weight(), napi_enable()), which
> also try to acquire the same lock, risking deadlock.
> 
> Similarly in the teardown path (mana_close()), netif_napi_disable() and
> netif_napi_del(), 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@...ux.microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@...rosoft.com>
> Reviewed-by: Shradha Gupta <shradhagupta@...ux.microsoft.com>
> Reviewed-by: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>

Reviewed-by: Long Li <longli@...rosoft.com>

> ---
> Changes in v2:
> * Use netdev_lock_ops_to_full() instead of if...else statements for napi
>   APIs.
> * Edit commit message.
> ---
>  drivers/net/ethernet/microsoft/mana/mana_en.c | 30 +++++++++++++------
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c
> b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index e68b8190bb7a..ca5e9c3d374b 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -1912,8 +1912,11 @@ 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);
> +			netdev_lock_ops_to_full(napi->dev);
> +			napi_disable_locked(napi);
> +			netif_napi_del_locked(napi);
> +			netdev_unlock_full_to_ops(napi->dev);
>  			apc->tx_qp[i].txq.napi_initialized = false;
>  		}
>  		mana_destroy_wq_obj(apc, GDMA_SQ, apc-
> >tx_qp[i].tx_object); @@ -2065,8 +2068,11 @@ static int
> mana_create_txq(struct mana_port_context *apc,
> 
>  		mana_create_txq_debugfs(apc, i);
> 
> -		netif_napi_add_tx(net, &cq->napi, mana_poll);
> -		napi_enable(&cq->napi);
> +		set_bit(NAPI_STATE_NO_BUSY_POLL, &cq->napi.state);
> +		netdev_lock_ops_to_full(net);
> +		netif_napi_add_locked(net, &cq->napi, mana_poll);
> +		napi_enable_locked(&cq->napi);
> +		netdev_unlock_full_to_ops(net);
>  		txq->napi_initialized = true;
> 
>  		mana_gd_ring_cq(cq->gdma_cq, SET_ARM_BIT); @@ -2102,9
> +2108,11 @@ static void mana_destroy_rxq(struct mana_port_context *apc,
>  	if (napi_initialized) {
>  		napi_synchronize(napi);
> 
> -		napi_disable(napi);
> -
> -		netif_napi_del(napi);
> +		netdev_lock_ops_to_full(napi->dev);
> +		napi_disable_locked(napi);
> +		netif_napi_del_locked(napi);
> +		netdev_unlock_full_to_ops(napi->dev);
>  	}
>  	xdp_rxq_info_unreg(&rxq->xdp_rxq);
> 
> @@ -2355,14 +2363,18 @@ static struct mana_rxq *mana_create_rxq(struct
> mana_port_context *apc,
> 
>  	gc->cq_table[cq->gdma_id] = cq->gdma_cq;
> 
> -	netif_napi_add_weight(ndev, &cq->napi, mana_poll, 1);
> +	netdev_lock_ops_to_full(ndev);
> +	netif_napi_add_weight_locked(ndev, &cq->napi, mana_poll, 1);
> +	netdev_unlock_full_to_ops(ndev);
> 
>  	WARN_ON(xdp_rxq_info_reg(&rxq->xdp_rxq, ndev, rxq_idx,
>  				 cq->napi.napi_id));
>  	WARN_ON(xdp_rxq_info_reg_mem_model(&rxq->xdp_rxq,
> MEM_TYPE_PAGE_POOL,
>  					   rxq->page_pool));
> 
> -	napi_enable(&cq->napi);
> +	netdev_lock_ops_to_full(ndev);
> +	napi_enable_locked(&cq->napi);
> +	netdev_unlock_full_to_ops(ndev);
> 
>  	mana_gd_ring_cq(cq->gdma_cq, SET_ARM_BIT);
>  out:
> --
> 2.34.1