[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250117172445.7719a86b@kernel.org>
Date: Fri, 17 Jan 2025 17:24:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Paolo Abeni
<pabeni@...hat.com>, netdev@...r.kernel.org, Simon Horman
<horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...zon.com>,
eric.dumazet@...il.com
Subject: Re: [PATCH net-next] net: introduce netdev_napi_exit()
On Fri, 17 Jan 2025 23:21:13 +0000 Eric Dumazet wrote:
> After 1b23cdbd2bbc ("net: protect netdev->napi_list with netdev_lock()")
> it makes sense to iterate through dev->napi_list while holding
> the device lock.
>
> Also call synchronize_net() at most one time.
I suspected you may send this :)
I was wondering whether we have to call sync_rcu() at all, Joe moved
unhashing the NAPI to napi_disable(). Assuming the driver is sane
it will call napi_disable() at latest in ndo_uninit(), and there's
already a synchronize_net() between ndo_uninit() and free.
But maybe drivers are not sane. We don't have
/* napi_disable() sets the SCHED bit */
WARN_ON(!test_bit(NAPI_STATE_SCHED, &val));
in netif_napi_del(). I think we should add it, after Joe's changes
if driver doesn't disable the napi it will leave a stale pointer
in the hash table.
In any case, your change makes sense:
Reviewed-by: Jakub Kicinski <kuba@...nel.org>
Powered by blists - more mailing lists