On Fri, Jun 05, 2026 at 04:13:15PM -0700, Jakub Kicinski wrote: > On Thu, 4 Jun 2026 22:29:29 -0700 Erni Sri Satya Vennela wrote: > > I tried two netdev_lock-based variants. > > > > mana_query_link_cfg() has four callers: > > > > 1 ethtool ioctl/netlink - has RTNL - has > > netdev->lock > > 2 sysfs speed_show/duplex_show - has RTNL - no > > netdev->lock > > 3 netvsc_get_link_ksettings VF forward - has RTNL - no > > netdev->lock > > 4 mana_shaper_set - no RTNL - has netdev->lock > > > > No existing lock covers all four. > > How fresh is your tree? The just-minted commit 9f275c2e9020 should > address the gap, I believe?
Hi Jakub, Thanks for pointing out the commit 9f275c2e9020. It does close the gap. My analysis was against a tree that predated it but the commit landed on net-next on Jun 4 21:30 UTC and my reply went out about an hour later, so the rebase that picked it up hadn't happened on my end yet. I've now rebased to current net-next and re-walked the four callers of mana_query_link_cfg(). All of them hold netdev->lock by the time they reach mana_query_link_cfg(), and the race scenarios I described no longer apply. Thanks, Vennela
