From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88BD433436A for ; Thu, 23 Apr 2026 22:27:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983237; cv=none; b=kK62OMykw7Gm7A+T7kVkfhFNRqHIeiADgSGhjmyHs8D1Be/+TpqCwJGAIFUE/xlTCMLZd3DZV38PwxLczPwSvs85alxH/kP1d71zYwfBEUz40MF3igFURS+5DmglLH5vb+bW/KsBw6UZL1qiwYZsw1/aLFoC+ReOJ40khVzxsxI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983237; c=relaxed/simple; bh=K/rv7vg9o1YKpDguK+R50Qfy17vzgHgNh9qMLvluVBk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ERlT4ao+gHZszZuzb7yheLpGksiztIUoMNOYa6KGzCbybdxC+tOrIhhEo68oaqIugGygQImzG1n3B93n4CzfqVmGQQhKy28ys2BR7hOQ9yX8xLxbtFOGg6W5RTD2/2aaO+S8mg6xyDdYpN+8MLcl5jzAt54zwf82mLyrYhLZbUQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net; spf=pass smtp.mailfrom=queasysnail.net; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b=TVTbuRAV; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=M6wmyyVt; arc=none smtp.client-ip=202.12.124.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b="TVTbuRAV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="M6wmyyVt" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 52AB17A0140; Thu, 23 Apr 2026 18:27:13 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 23 Apr 2026 18:27:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queasysnail.net; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1776983233; x= 1777069633; bh=VN2AmLlnP64m1QZ3DL+eF3J0eOsS0udkViE9JKY2i6c=; b=T VTbuRAVLWFhgECrY8GBvfgeB8OKwpRkH0OuUBU+XAlu+0z5GB0Tr+7LoE+Rpd3yn jnOXgNE0bGYzDYO+C5oQHV+rShp5Wfn+cbjsrVN5KyOlrJGSmURF+A17gb03dLkJ g/JfzVCSNAVa5CAPA5mDsXaBdYOtFOkT+AHpTm3CVNNE19u851k2ci35+Vh/3cro 5maGI6mVSY6fiCl6Lsik8UDMVIxpQnvQoTzkjhTxnAiTQKSSRA/QiTyYfqyu+c4W 4wKLzTtfZe7beS5Sic/TRSd0U8vxKmxSM1WHNlhAi9gJOzNn8LZxglZeblEs5HfX NU8R/Wv20uCf2FZVoCSDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1776983233; x=1777069633; bh=VN2AmLlnP64m1QZ3DL+eF3J0eOsS0udkViE 9JKY2i6c=; b=M6wmyyVtPXjj5VD2VJTV4AJwcPuh8sGI2j4pw9SSZCNFz+AWa0A GQiCxmJ1uXYQ4uSRYobcpqv9+SQYbPtJBkHxaREhu3HBWf8y4JOYZCY3tF8ePBY7 Yot1Bo+yr4exZElXnPWWhCPhAwHMd9dkQzAQJXNN/Jt9VKOqdkC/XRIKcozpZDIo ZJ4iNROoOKYTyy8c+CRTorz6sCHw3o33tggpoBo+ZwRaZWJknU5cFyCiFtT6pkQa po48LmK07+Ccq7qiiS9QAzyvrj1khKCdGiaR5EiApVtYYBdJAieX3DpbQvYwgk56 T8fUKbWutulTUwJ4/P+o36KncUA1iaiQNBw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdeikeefhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdertddttdejnecuhfhrohhmpefurggsrhhinhgr ucffuhgsrhhotggruceoshgusehquhgvrghshihsnhgrihhlrdhnvghtqeenucggtffrrg htthgvrhhnpeeuhffhfffgfffhfeeuiedugedtfefhkeegteehgeehieffgfeuvdeuffef gfduffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsugesqhhuvggrshihshhnrghilhdrnhgvthdpnhgspghrtghpthhtohepledpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepkhhusggrsehkvghrnhgvlhdrohhrghdprhgtph htthhopegrnhhtohhnihhosehophgvnhhvphhnrdhnvghtpdhrtghpthhtohepnhgvthgu vghvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgrlhhfsehmrghnug gvlhgsihhtrdgtohhmpdhrtghpthhtohepphgrsggvnhhisehrvgguhhgrthdrtghomhdp rhgtphhtthhopegrnhgurhgvfidonhgvthguvghvsehluhhnnhdrtghhpdhrtghpthhtoh epuggrvhgvmhesuggrvhgvmhhlohhfthdrnhgvthdprhgtphhtthhopegvughumhgriigv thesghhoohhglhgvrdgtohhmpdhrtghpthhtohepihhmvhegsggvlhesghhmrghilhdrtg homh X-ME-Proxy: Feedback-ID: i934648bf:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 23 Apr 2026 18:27:12 -0400 (EDT) Date: Fri, 24 Apr 2026 00:27:10 +0200 From: Sabrina Dubroca To: Jakub Kicinski Cc: Antonio Quartulli , netdev@vger.kernel.org, Ralf Lici , Paolo Abeni , Andrew Lunn , "David S. Miller" , Eric Dumazet , Hyunwoo Kim Subject: Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer Message-ID: References: <20260422123242.530882-1-antonio@openvpn.net> <20260422123242.530882-2-antonio@openvpn.net> <20260422192050.7c4ca760@kernel.org> <7481bc31-44f6-43ae-b3aa-07002644d9e6@openvpn.net> <9221605c-ad31-44f9-b3b7-db2237f75eb7@openvpn.net> <20260423103628.4ce6fc05@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260423103628.4ce6fc05@kernel.org> 2026-04-23, 10:36:28 -0700, Jakub Kicinski wrote: > On Thu, 23 Apr 2026 18:37:49 +0200 Sabrina Dubroca wrote: > > We could also wrap all of ovpn_peer_add (including the new reg_state > > check) in netdev_lock, since we can't move to NETREG_UNREGISTERING > > until netdev_lock is released (then I think we wouldn't need the > > READ_ONCE(reg_state)). But I don't know if that's an acceptable use of > > netdev_lock. > > Yup, fwiw it's a perfectly legitimate use case. Ok. There's still a worrying bit in nesting lock_sock under netdev_lock (ovpn_peer_add -> netdev_lock -> ovpn_peer_add_p2p -> unlock_ovpn -> ovpn_socket_release -> lock_sock). -- Sabrina