All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: Ilya Maximets <i.maximets@ovn.org>
Cc: netdev@vger.kernel.org,  Eelco Chaudron <echaudro@redhat.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>,
	 dev@openvswitch.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] openvswitch: vport: fix race between linking and the device notifier
Date: Thu, 14 May 2026 09:43:26 -0400	[thread overview]
Message-ID: <f7tik8qqf7l.fsf@redhat.com> (raw)
In-Reply-To: <41104c02-efb9-4f23-8e11-95afa6eef442@ovn.org> (Ilya Maximets's message of "Wed, 13 May 2026 18:55:59 +0200")

Ilya Maximets <i.maximets@ovn.org> writes:

> On 5/13/26 2:02 PM, Aaron Conole wrote:
>> Hi Ilya,
>> 
>> Ilya Maximets <i.maximets@ovn.org> writes:
>> 
>>> Sashiko reports that it is technically possible that we got the device
>>> reference, but by the time we're linking it to the OVS datapath, it
>>> may be already in the process of being deleted.  In this case if the
>>> notifier wins the race for RTNL, it will see that the device is not
>>> yet in the OVS datapath (ovs_netdev_get_vport() will fail in the
>>> dp_device_event()) and will do nothing.  Then the ovs_netdev_link()
>>> will take the RTNL and link the unregistering device to OVS datapath.
>>>
>>> Eventually, netdev_wait_allrefs_any() will re-broadcast the event and
>>> the device will be properly detached, but it will take at least a
>>> second before that happens, so it's not something we should rely on.
>>>
>>> Let's avoid linking the non-registered device in the first place.
>>>
>>> Note: As per documentation, RTNL doesn't protect the reg_state, but
>>> it actually does for all the state transitions we care about here,
>>> so it should not be necessary to use READ_ONCE or taking the instance
>>> lock.  We can still do that, but we have a few more places even in
>>> this file where the reg_state is accessed without those while under
>>> RTNL, and many more places like this across the kernel code, so it
>>> might make more sense to change all of them in a more centralized
>>> fashion in the future, if necessary.
>>>
>>> Fixes: ccb1352e76cf ("net: Add Open vSwitch kernel components.")
>>> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
>>> ---
>>>  net/openvswitch/vport-netdev.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
>>> index c42642075685d..de90d0541e172 100644
>>> --- a/net/openvswitch/vport-netdev.c
>>> +++ b/net/openvswitch/vport-netdev.c
>>> @@ -83,6 +83,11 @@ struct vport *ovs_netdev_link(struct vport *vport, bool tunnel)
>>>  	}
>>>  
>>>  	rtnl_lock();
>> 
>> As noted in your commit, this shouldn't cause any kind of issues, since
>> the next netdev_wait_allrefs_any() will make sure things look correct to
>> the users again.
>> 
>> That said, I agree this is good to do to prevent some confusion going to
>> the users.  I wonder if it makes sense to add a comment here noting
>> that.  Otherwise, if I were just freshly reading through the code it
>> wouldn't follow (all the places where ovs_netdev_link get called are in
>> the 'create' path).
>> 
>> WDYT?
>
> I'm not sure if the comment is necessary.  We're not creating a device here
> and it seems clear enough that we shouldn't be linking devices that are not
> registered, even if there are no races.  But I could add something like:
>
> /* Do not link devices that are not registered to avoid a potential
>  * race with the NETDEV_UNREGISTER notification in dp_device_event().
>  */
>
> WDYT?

That comment makes sense to me.

> Best regards, Ilya Maximets.


      reply	other threads:[~2026-05-14 13:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  9:54 [PATCH net] openvswitch: vport: fix race between linking and the device notifier Ilya Maximets
2026-05-13 12:02 ` Aaron Conole
2026-05-13 16:55   ` Ilya Maximets
2026-05-14 13:43     ` Aaron Conole [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=f7tik8qqf7l.fsf@redhat.com \
    --to=aconole@redhat.com \
    --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=kuba@kernel.org \
    --cc=linux-kernel@vger.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.