From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 EFC58207A32 for ; Mon, 27 Apr 2026 20:22:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777321353; cv=none; b=grqPlSFLzvZBKVz91YmD4YzXmSA3ha5P4YatjFK+bKo04sWKAjBtw3UUVWmspTxtzCeEJjRM62/FfPE0BkzqzUl0OxDRWLRHYYgZZZhG5vHhFIfOyrlrg9R0sQAa/03fLe/Cawy8NZnil5sD1idQAc7z7z5lLJQG/D795lWz4us= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777321353; c=relaxed/simple; bh=kHXLUA61nlqyrP7LBjoKHDFEG9Pa+X067JwPtNyRei8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CiapSDbxzr/33ThcicOC1KNeF/vP7ZvN4B9BcZdxLaY2IOgJXVojanIHhaIsWWXb3AtX+cmU077ZfDqzhm+TzV0GfModJvV25RfT8Qb8b4JlyjHxqIIrXBpv1cxF++JsfV9/FzTLlipi7Pg282w0Yre73MpNsjvXQrZoutfewrc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aKAtNUM3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aKAtNUM3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58664C19425; Mon, 27 Apr 2026 20:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777321352; bh=kHXLUA61nlqyrP7LBjoKHDFEG9Pa+X067JwPtNyRei8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aKAtNUM3Ew773d156KR4mLC90ay8I5UVb9H1N4wnz8B68GIjGlxM3yRNanvhDeeGt sqNQznsY0HloZEw2/QXGTJgS53P4baOaEw6SfAqbfQ9Lgv12O5VSQcKBfqG5SOX+Py 0F00y+ljCbURR8EqpGYsQbGtF+kc1cC9C6jqdHlHW3nbKe6NLyL+vEEpEVUS1aNpi7 bhYCJ1Vbg2wPIckAnnSHWEF/T1jTYvgcQhHJpH54tEAT2mcAz/W70CjIfDbOuLnEH8 ayUr5SL8ptbwVWzReF4b7jsIBPE6cOhNkhA470IROCwWGFZHq7E3akKdobxyKpKkG8 fyVb+BhCUh/QQ== Date: Mon, 27 Apr 2026 13:22:31 -0700 From: Jakub Kicinski To: Sabrina Dubroca 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: <20260427132231.2621be72@kernel.org> In-Reply-To: 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=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 24 Apr 2026 00:27:10 +0200 Sabrina Dubroca wrote: > 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). No opinion on socket lock, TBH. It does indeed increase the potential for hard to trace deadlocks. But I'd think the ordering is intuitive - netdev lock "feels" heavier than socket lock.