On Tue, Jun 02, 2026 at 01:21:27PM -0700, Jakub Kicinski wrote:
> On Thu, 28 May 2026 11:07:51 -0700 Erni Sri Satya Vennela wrote:
> > mana_query_link_cfg() sends an HWC command to firmware on every call,
> > but the link speed and QoS values it returns only change when the
> > driver explicitly calls mana_set_bw_clamp(). This function is called
> > not only by userspace via ethtool get_link_ksettings, but also
> > periodically by hv_netvsc through netvsc_get_link_ksettings and by
> > the sysfs speed_show attribute via dev_attr_show, resulting in
> > unnecessary HWC traffic every few minutes.
>
> mana is ops-locked, right? Because you support net shapers
>
> Could you instead take the netdev_lock() in the work?
> It's already held around the user space originated calls.
Hi Jakub,
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.
A. netdev_assert_locked() in the mana_query_link_cfg() :
Lockdep WARN on every sysfs cat /sys/class/net/eth*/speed and every
periodic netvsc_get_link_ksettings() poll since callers 2 and 3 hold
RTNL only.
A slow firmware reply on callers 2/3 can land after mana_shaper_set
(caller 4) has changed the rate and invalidated the cache,
publishing a stale apc->speed / apc->max_speed as "cached valid".
Because the value is cached, the staleness then persists until the next
shaper change
B. ASSERT_RTNL() + netdev_lock_ops() inside mana_query_link_cfg():
Self-deadlocks on #1 (__dev_ethtool already holds it) and #4
(mana_shaper_set already holds it and calls mana_query_link_cfg() before
the clamp).
ASSERT_RTNL() also WARNs from #4 — shaper genl ops don't take RTNL.
Eg. Deadlock scenario:
__dev_ethtool()
netdev_lock_ops(dev) ← held
ops->get_link_ksettings()
mana_get_link_ksettings()
mana_query_link_cfg()
netdev_lock_ops(ndev) ← DEADLOCK
Can we consider private link_cfg_mutex which is orthogonal to RTNL and
netdev->lock and covers all four callers?
Thanks,
Vennela
