mbox series

[net-next,v3,0/7] devlink: fix a deadlock when taking devlink instance lock while holding RTNL lock

Message ID 20231013121029.353351-1-jiri@resnulli.us (mailing list archive)
Headers show
Series devlink: fix a deadlock when taking devlink instance lock while holding RTNL lock | expand

Message

Jiri Pirko Oct. 13, 2023, 12:10 p.m. UTC
From: Jiri Pirko <jiri@nvidia.com>

devlink_port_fill() may be called sometimes with RTNL lock held.
When putting the nested port function devlink instance attrs,
current code takes nested devlink instance lock. In that case lock
ordering is wrong.

Patch #1 is a dependency of patch #2.
Patch #2 converts the peernet2id_alloc() call to rely in RCU so it could
         called without devlink instance lock.
Patch #3 takes device reference for devlink instance making sure that
         device does not disappear before devlink_release() is called.
Patch #4 benefits from the preparations done in patches #2 and #3 and
         removes the problematic nested devlink lock aquisition.
Patched #5-#7 improve documentation to reflect this issue so it is
              avoided in the future.

Jiri Pirko (7):
  net: treat possible_net_t net pointer as an RCU one and add
    read_pnet_rcu()
  devlink: call peernet2id_alloc() with net pointer under RCU read lock
  devlink: take device reference for devlink object
  devlink: don't take instance lock for nested handle put
  Documentation: devlink: add nested instance section
  Documentation: devlink: add a note about RTNL lock into locking
    section
  devlink: document devlink_rel_nested_in_notify() function

 Documentation/networking/devlink/index.rst | 28 ++++++++++++++++++
 include/net/net_namespace.h                | 15 ++++++++--
 net/devlink/core.c                         | 34 ++++++++++++----------
 net/devlink/netlink.c                      | 12 ++++++--
 4 files changed, 68 insertions(+), 21 deletions(-)

Comments

patchwork-bot+netdevbpf@kernel.org Oct. 18, 2023, 8:30 a.m. UTC | #1
Hello:

This series was applied to netdev/net-next.git (main)
by David S. Miller <davem@davemloft.net>:

On Fri, 13 Oct 2023 14:10:22 +0200 you wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> devlink_port_fill() may be called sometimes with RTNL lock held.
> When putting the nested port function devlink instance attrs,
> current code takes nested devlink instance lock. In that case lock
> ordering is wrong.
> 
> [...]

Here is the summary with links:
  - [net-next,v3,1/7] net: treat possible_net_t net pointer as an RCU one and add read_pnet_rcu()
    https://git.kernel.org/netdev/net-next/c/2034d90ae41a
  - [net-next,v3,2/7] devlink: call peernet2id_alloc() with net pointer under RCU read lock
    https://git.kernel.org/netdev/net-next/c/c503bc7df602
  - [net-next,v3,3/7] devlink: take device reference for devlink object
    https://git.kernel.org/netdev/net-next/c/a380687200e0
  - [net-next,v3,4/7] devlink: don't take instance lock for nested handle put
    https://git.kernel.org/netdev/net-next/c/b5f4e371336a
  - [net-next,v3,5/7] Documentation: devlink: add nested instance section
    https://git.kernel.org/netdev/net-next/c/b6f23b319aad
  - [net-next,v3,6/7] Documentation: devlink: add a note about RTNL lock into locking section
    https://git.kernel.org/netdev/net-next/c/bb11cf9b2c4a
  - [net-next,v3,7/7] devlink: document devlink_rel_nested_in_notify() function
    https://git.kernel.org/netdev/net-next/c/5d77371e8c85

You are awesome, thank you!