[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250212182330.GI1615191@kernel.org>
Date: Wed, 12 Feb 2025 18:23:30 +0000
From: Simon Horman <horms@...nel.org>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Andy Whitcroft <apw@...onical.com>, Joe Perches <joe@...ches.com>,
Dwaipayan Ray <dwaipayanray1@...il.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next] checkpatch: Discourage a new use of
rtnl_lock() variants.
On Tue, Feb 11, 2025 at 04:04:47PM +0900, Kuniyuki Iwashima wrote:
> rtnl_lock() is a "Big Kernel Lock" in the networking slow path
> and still serialises most of RTM_(NEW|DEL|SET)* rtnetlink requests.
>
> Commit 76aed95319da ("rtnetlink: Add per-netns RTNL.") started a
> very large, in-progress, effort to make the RTNL lock scope per
> network namespace.
>
> However, there are still some patches that newly use rtnl_lock(),
> which is now discouraged, and we need to revisit it later.
>
> Let's warn about the case by checkpatch.
>
> The target functions are as follows:
>
> * rtnl_lock()
> * rtnl_trylock()
> * rtnl_lock_interruptible()
> * rtnl_lock_killable()
>
> and the warning will be like:
>
> WARNING: A new use of rtnl_lock() variants is discouraged, try to use rtnl_net_lock(net) variants
> #18: FILE: net/core/rtnetlink.c:79:
> + rtnl_lock();
>
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
> ---
> It would be nice if this patch goes through net-next.git to catch
> new rtnl_lock() users by netdev CI.
Reviewed-by: Simon Horman <horms@...nel.org>
Powered by blists - more mailing lists