From nobody Fri Jun 12 18:34:16 2026 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27A9A3DB964 for ; Wed, 13 May 2026 09:55:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.65 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778666152; cv=none; b=VtjhZa7htPt5J89XCVkxKYNqzQZ7py1tIsINH8EKvkf+p+NyJ3XJJhyG5u+UoQ7nVgm7a/KnMDdd5wYsCx9ZRxa51Pd313aSkSq98gZlJ3Xhbi1WUuZgP6VQOMcbvj+xxZv+F4ciwK0NtmfFM5bFIqtEzqAsCjOZFyLC5JlPQ/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778666152; c=relaxed/simple; bh=HK3AEjdpUCDYcmZMDKscRl09Shu5Uh9iMAdbuP4JJAE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dOp9uL7c4Dig46FCZU2vDUqEqKA11yg/eFmOVROxCT9nwGcsw0qqWh3rda4+dW1zCATO5UIwhZ739MwlmETU1LbjOSPSYwdSRRJKbiySQ5MsRETC/kjHn2XmWAPJer6NeXEtqVIANCkJ6Z+P1oK8oKFna7V2MJiyKvU8ehCmI0M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ovn.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.221.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ovn.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f65.google.com with SMTP id ffacd0b85a97d-449de065cb3so5953620f8f.2 for ; Wed, 13 May 2026 02:55:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778666146; x=1779270946; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5Bmq07OY8R1+Ffy1WSrvxPM6bplPMC10H/ezoamnZ7c=; b=DGajTKBUpFUQlZ+9KCpEw3sYZ8vUlX00li9Jkqf7ouyojC24StB1nb38zCkAsZV4lr UeXvOIpOnCVwobuvl9KNSnMaEoUxWBdLpdeXuTuIFzwbxei9sWFzB/zTqGr4+QD8EAZF fNzsv+l4x4mfBWjRTiL7CE3gsqdXKp/LeFBsQ6HI9mShvtkktK+2IQ8krpIodl35ZHSk PrjWafsdd2l3tFwYI+N3YOHPlKAjYLn9flZj1vSAtIgnIzuXl7a1cIilh2BhDVP5Q2jP P9IlT5pE9B5I5Rci9SkPg2CEGx6lDyroOHhTTesMzlABOxMsQFYJ4YdZkU/BseMq/Ckr FZ+w== X-Forwarded-Encrypted: i=1; AFNElJ+CNjEfu6Tx9vlJZFSN5GQSPtmga8Cm8sNg64MXI7l1ZBgA2tPd3TLpLOIiTqeEVlK/uvhfzW0OhFCE3Ac=@vger.kernel.org X-Gm-Message-State: AOJu0YyqfdxnKW9OHC9vNi8t2m5NI2KbTC00Y/NPfbpfz9nqTw1PJfFS /XWFOvkNs+FNxf/wIlt76ixWzIbBWCjxEw8WxLazwrvZxe18KFui+Q/g X-Gm-Gg: Acq92OHSwr21tmZ26CrXfYWB+pP19jFjwZojcib50YxaDoOvRFxptILXGiszxYDxP6k GiwN4SZWAguurXjoOTlKTdjbXGyfEuoHwoZXGMTaepBSehyKX/gB7gYcBZHcddalQuw9fxqpYXR cJNjL/ACLTVHYHQRKPPOSvRfkSl6e94L2+odf1fySpC3YRAGUGGHTyaLtCufesXLQvCjkzeOjT/ fA3KG9eObt/CQJhXbNGMBLPc4KxqSrLGXQETXl1kmTEksc7D6t7DPtTTlFdRmcMaOt6HKCQMoG1 SV8+LdNsEzp/lV0dHOKo0ayklQsiCu281muu8DEvlKBEoiqwYqN/M90XcP+EJXcehQsOXcUCHfW N5AIq9LrIJjti6YDgd3JawM+pePWQ0sYB15vcRbhNYWKrfbIch5YjUh67agbfVKZpUn1Xw/0JCy aU2soujOOWcvpSX09FRJPcJsyXlNz0Px87DvZV341a9rG2ls6Ss7RLZtaJsus= X-Received: by 2002:a05:6000:200f:b0:44b:7ec9:2d76 with SMTP id ffacd0b85a97d-45c790b2abbmr3507243f8f.7.1778666145933; Wed, 13 May 2026 02:55:45 -0700 (PDT) Received: from im-t490s.redhat.com (37-48-40-237.nat.epc.tmcz.cz. [37.48.40.237]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548eb75c29sm38125865f8f.9.2026.05.13.02.55.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 02:55:45 -0700 (PDT) From: Ilya Maximets To: netdev@vger.kernel.org Cc: Aaron Conole , Eelco Chaudron , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , dev@openvswitch.org, linux-kernel@vger.kernel.org, Ilya Maximets Subject: [PATCH net] openvswitch: vport: fix race between linking and the device notifier Date: Wed, 13 May 2026 11:54:56 +0200 Message-ID: <20260513095541.2010516-1-i.maximets@ovn.org> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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) } =20 rtnl_lock(); + if (vport->dev->reg_state !=3D NETREG_REGISTERED) { + err =3D -ENODEV; + goto error_put_unlock; + } + err =3D netdev_master_upper_dev_link(vport->dev, get_dpdev(vport->dp), NULL, NULL, NULL); --=20 2.53.0