On Tue, 2025-05-06 at 11:13 -0700, Stanislav Fomichev wrote:
On 05/06, Cosmin Ratiu wrote:
Right, but netdev_sync_lower_features calls lower's __netdev_update_features only for NETIF_F_UPPER_DISABLES. So it doesn't propagate all features, only LRO AFAICT.
Got it, I didn't look into what netdev_sync_lower_features actually does besides noticing it can call __netdev_update_feature...
In any case, please hold off with picking this patch up, it seems there's a possibility of a real deadlock. Here's the scenario:
============================================ WARNING: possible recursive locking detected -------------------------------------------- ethtool/44150 is trying to acquire lock: ffff8881364e8c80 (&dev_instance_lock_key#7){+.+.}-{4:4}, at: __netdev_update_features+0x31e/0xe20
but task is already holding lock: ffff8881364e8c80 (&dev_instance_lock_key#7){+.+.}-{4:4}, at: ethnl_set_features+0xbc/0x4b0 and the lock comparison function returns 0:
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(&dev_instance_lock_key#7); lock(&dev_instance_lock_key#7);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by ethtool/44150: #0: ffffffff830e5a50 (cb_lock){++++}-{4:4}, at: genl_rcv+0x15/0x40 #1: ffffffff830cf708 (rtnl_mutex){+.+.}-{4:4}, at: ethnl_set_features+0x88/0x4b0 #2: ffff8881364e8c80 (&dev_instance_lock_key#7){+.+.}-{4:4}, at: ethnl_set_features+0xbc/0x4b0
stack backtrace: Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x163c/0x2f00 lock_acquire+0xd3/0x2e0 __mutex_lock+0x98/0xf10 __netdev_update_features+0x31e/0xe20 netdev_update_features+0x1f/0x60 vlan_device_event+0x57d/0x930 [8021q] notifier_call_chain+0x3d/0x100 netdev_features_change+0x32/0x50 ethnl_set_features+0x17e/0x4b0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 [...]
I'm not sure how to solve this yet... Cosmin.