From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Eelco Chaudron <echaudro@redhat.com>,
Adrian Moreno <amorenoz@redhat.com>
Cc: Aaron Conole <aconole@redhat.com>,
Ilya Maximets <i.maximets@ovn.org>,
Alexei Starovoitov <ast@kernel.org>,
Jesse Gross <jesse@nicira.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, dev@openvswitch.org
Subject: Re: [PATCH v2] net: openvswitch: Avoid needlessly taking the RTNL on vport destroy
Date: Mon, 15 Dec 2025 12:58:48 +0100 [thread overview]
Message-ID: <87qzswklc7.fsf@toke.dk> (raw)
In-Reply-To: <198C2570-F384-4385-8A6B-84DCC38BB5F5@redhat.com>
Eelco Chaudron <echaudro@redhat.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@redhat.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.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 :)
-Toke
next prev parent reply other threads:[~2025-12-15 11:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 11:50 [PATCH v2] net: openvswitch: Avoid needlessly taking the RTNL on vport destroy Toke Høiland-Jørgensen
2025-12-15 8:41 ` Eelco Chaudron
2025-12-15 11:58 ` Toke Høiland-Jørgensen [this message]
2025-12-15 12:31 ` Eelco Chaudron
2025-12-22 11:29 ` Paolo Abeni
2025-12-22 11:44 ` Eelco Chaudron
2025-12-15 13:14 ` Aaron Conole
[not found] ` <CAKDHXDHsdfRfaDyfzoTymsPkm=mPdFtJOA=GHb6HGx6TjvYA7w@mail.gmail.com>
2025-12-16 11:59 ` Adrián Moreno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87qzswklc7.fsf@toke.dk \
--to=toke@redhat.com \
--cc=aconole@redhat.com \
--cc=amorenoz@redhat.com \
--cc=ast@kernel.org \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=i.maximets@ovn.org \
--cc=jesse@nicira.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.