Thread (12 messages) 12 messages, 3 authors, 2021-11-01

Re: [PATCH net-next v2 0/4] improve ethtool/rtnl vs devlink locking

From: patchwork-bot+netdevbpf@kernel.org
Date: 2021-11-01 13:37:06

Hello:

This series was applied to netdev/net-next.git (master)
by David S. Miller [off-list ref]:

On Sat, 30 Oct 2021 10:18:47 -0700 you wrote:
During ethtool netlink development we decided to move some of
the commmands to devlink. Since we don't want drivers to implement
both devlink and ethtool version of the commands ethtool ioctl
falls back to calling devlink. Unfortunately devlink locks must
be taken before rtnl_lock. This results in a questionable
dev_hold() / rtnl_unlock() / devlink / rtnl_lock() / dev_put()
pattern.

[...]
Here is the summary with links:
  - [net-next,v2,1/4] ethtool: push the rtnl_lock into dev_ethtool()
    https://git.kernel.org/netdev/net-next/c/f49deaa64af1
  - [net-next,v2,2/4] ethtool: handle info/flash data copying outside rtnl_lock
    https://git.kernel.org/netdev/net-next/c/095cfcfe13e5
  - [net-next,v2,3/4] devlink: expose get/put functions
    https://git.kernel.org/netdev/net-next/c/46db1b77cd4f
  - [net-next,v2,4/4] ethtool: don't drop the rtnl_lock half way thru the ioctl
    https://git.kernel.org/netdev/net-next/c/1af0a0948e28

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help