[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250417192547.36a7503e@kernel.org>
Date: Thu, 17 Apr 2025 19:25:47 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Sathesh B Edara <sedara@...vell.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <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>, Paolo Abeni
<pabeni@...hat.com>
Subject: Re: [PATCH net v3] octeon_ep_vf: Resolve netdevice usage count
issue
On Wed, 16 Apr 2025 13:26:43 -0700 Jacob Keller wrote:
> > @@ -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?
Looks like something I would have asked them to do :)
But it was probably merged before I could review next version ?
I mean, passing NULL for the tracker is... quite something.
> 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.
It does, but before unregistering :/
Sathesh, schedule_work() returns a value. You should use it.
Powered by blists - more mailing lists