linux-kernel - Re: [PATCH net v3] octeon_ep_vf: Resolve netdevice usage count issue

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: <07549649-3712-47b9-917b-c5001f9761cb@intel.com>
Date: Wed, 16 Apr 2025 13:26:43 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Sathesh B Edara <sedara@...vell.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
CC: <hgani@...vell.com>, <vimleshk@...vell.com>, Veerasenareddy Burru
	<vburru@...vell.com>, Shinas Rasheed <srasheed@...vell.com>, Satananda Burla
	<sburla@...vell.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net v3] octeon_ep_vf: Resolve netdevice usage count issue



On 4/16/2025 3:25 AM, Sathesh B Edara wrote:
> The netdevice usage count increases during transmit queue timeouts
> because netdev_hold is called in ndo_tx_timeout, scheduling a task
> to reinitialize the card. Although netdev_put is called at the end
> of the scheduled work, rtnl_unlock checks the reference count during
> cleanup. This could cause issues if transmit timeout is called on
> multiple queues. Therefore, netdev_hold and netdev_put have been removed.
> 
> Fixes: cb7dd712189f ("octeon_ep_vf: Add driver framework and device initialization")
> Signed-off-by: Sathesh B Edara <sedara@...vell.com>
> ---
> Changes:
> V3:
>   - Added more description to commit message
> V2:
>   - Removed redundant call
> 
>  drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_main.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_main.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_main.c
> index 18c922dd5fc6..5d033bc66bdf 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_main.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_main.c
> @@ -819,7 +819,6 @@ static void octep_vf_tx_timeout_task(struct work_struct *work)
>  		octep_vf_open(netdev);
>  	}
>  	rtnl_unlock();
> -	netdev_put(netdev, NULL);
>  }
>  
>  /**
> @@ -834,7 +833,6 @@ static void octep_vf_tx_timeout(struct net_device *netdev, unsigned int txqueue)
>  {
>  	struct octep_vf_device *oct = netdev_priv(netdev);
>  
> -	netdev_hold(netdev, NULL, GFP_ATOMIC);
>  	schedule_work(&oct->tx_timeout_task);
>  }
I guess the thought was that we need to hold because we scheduled a work
item?

Presumably the driver would simply cancel_work_sync() on this timeout
task before it attempts to release its own reference on the netdev, so
this really doesn't protect anything.

Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>

>