All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Adrián Moreno" <amorenoz@redhat.com>,
	"Eelco Chaudron" <echaudro@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 net] net: openvswitch: Avoid needlessly taking the RTNL on vport destroy
Date: Wed, 10 Dec 2025 17:40:50 +0100	[thread overview]
Message-ID: <87a4zqmgrx.fsf@toke.dk> (raw)
In-Reply-To: <CAG=2xmPCYdYBk9zc9EHt2dmGUBuXJHqnMLByac17UHOqSt2CFw@mail.gmail.com>

Adrián Moreno <amorenoz@redhat.com> writes:

>> Not fully sure I understand the code path you are referring to, but
>> if it’s through
>> ovs_dp_notify_wq()->dp_detach_port_notify()->ovs_dp_detach_port(), it
>> takes the ovs_lock().
>
> The codepath described by Toke is:
> (netdev gets unregistered outside of OVS) ->
> dp_device_event (under RTNL) -> ovs_netdev_detach_dev()
> (IFF_OVS_DATAPATH is cleared)
>
> Then dp_notify_work is scheduled and it does what you mention:
> ovs_dp_notify_wq (lock ovs_mutex) -> dp_detach_port_notify -> ovs_dp_detach_port
>     -> ovs_vport_del -> netdev_destroy (at this point
> netif_is_ovs_port is false)
>
> The first part of this codepath (NETDEV_UNREGISTER notification) happens
> under RTNL, not under ovs_mutex and it manipulates vport->dev->priv_flags.
>
> So in theory we could receive the netdev notification while we process a
> ovs_vport_cmd_del() command from userspace, which also ends up calling
> netdev_destroy.

Yeah, I agree, it's not guaranteed that reading the flags outside the
lock will be race free, so re-checking seems safer here (and is also
quite cheap).

There does seem to be other uses of netif_is_ovs_port() that are outside
the RTNL, though, so maybe not such a likely race in practice?

Anyway, I'll respin with a comment.

-Toke


      reply	other threads:[~2025-12-10 16:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-10 12:59 [PATCH net] net: openvswitch: Avoid needlessly taking the RTNL on vport destroy Toke Høiland-Jørgensen
2025-12-10 13:28 ` Eelco Chaudron
2025-12-10 15:12   ` Adrián Moreno
2025-12-10 15:30     ` Eelco Chaudron
2025-12-10 15:59       ` Adrián Moreno
2025-12-10 16:40         ` Toke Høiland-Jørgensen [this message]

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=87a4zqmgrx.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.