[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <E6D49A6B-A0F7-46B6-BC32-A5C4ADAFD6DC@redhat.com>
Date: Mon, 15 Dec 2025 13:31:53 +0100
From: Eelco Chaudron <echaudro@...hat.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Adrian Moreno <amorenoz@...hat.com>, Aaron Conole <aconole@...hat.com>,
Ilya Maximets <i.maximets@....org>, Alexei Starovoitov <ast@...nel.org>,
Jesse Gross <jesse@...ira.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [PATCH v2] net: openvswitch: Avoid needlessly taking the RTNL on
vport destroy
On 15 Dec 2025, at 12:58, Toke Høiland-Jørgensen wrote:
> Eelco Chaudron <echaudro@...hat.com> writes:
>
>> On 11 Dec 2025, at 12:50, Toke Høiland-Jørgensen wrote:
>>
>>> The openvswitch teardown code will immediately call
>>> ovs_netdev_detach_dev() in response to a NETDEV_UNREGISTER notification.
>>> It will then start the dp_notify_work workqueue, which will later end up
>>> calling the vport destroy() callback. This callback takes the RTNL to do
>>> another ovs_netdev_detach_port(), which in this case is unnecessary.
>>> This causes extra pressure on the RTNL, in some cases leading to
>>> "unregister_netdevice: waiting for XX to become free" warnings on
>>> teardown.
>>>
>>> We can straight-forwardly avoid the extra RTNL lock acquisition by
>>> checking the device flags before taking the lock, and skip the locking
>>> altogether if the IFF_OVS_DATAPATH flag has already been unset.
>>>
>>> Fixes: b07c26511e94 ("openvswitch: fix vport-netdev unregister")
>>> Tested-by: Adrian Moreno <amorenoz@...hat.com>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>>
>> Guess the change looks good, but I’m waiting for some feedback from
>> Adrian to see if this change makes sense.
>
> OK.
>
>> Any luck reproducing the issue it’s supposed to fix?
>
> We got a report from the customer that originally reported it (who had
> their own reproducer) that this patch fixes their issue to the point
> where they can now delete ~2000 pods/node without triggering the
> unregister_netdevice warning at all (where before it triggered at around
> ~500 pod deletions). So that's encouraging :)
That’s good news; just wanted to make sure we are not chasing a red herring :)
Acked-by: Eelco Chaudron echaudro@...hat.com
Powered by blists - more mailing lists