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 3BF9025D548 for ; Fri, 14 Feb 2025 11:14:42 +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=1739531683; cv=none; b=ns+2P1tUen80o8O4WTaaLerCN6Fuishb5XFYOSIK0BPrOUaV/ioAmXu8X/V0M0m3uTv93iuTyl0MLeoiwqhXtLy2KGnBl3+k2CP5KnbaEv8W1s86OaoZz0WsWfSLLRXmF/Uu8UPXLwumRr71WiGm+qg+u18zKgBAhpzW0Kg4eP8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739531683; c=relaxed/simple; bh=h0lJOOGwOy62qvljHZCMnbxB3nLk6xpE2zTPjM/UO1w=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=KbXpoxYsPlxfE46qNnQk5SGb+HvTzWVWWCcd5WvR37VTo5iYsT89WJjN+4kmNRj6tf6miGb/IXMeN2OKihXl4RXzXPrwLK1HauzRe+fBeKYpr7seig0ywe4+Y6Te4nlD61duKGRyaPbXIqbcc2hDBIq19P0G5Ox8JsXiF75RCbc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ocH3TY7o; 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="ocH3TY7o" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37094C4AF0B; Fri, 14 Feb 2025 11:14:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739531682; bh=h0lJOOGwOy62qvljHZCMnbxB3nLk6xpE2zTPjM/UO1w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ocH3TY7oh6QnyTnSMB7GtnWO83350elHqsUkln5QUOo8dAUEGytA2WwFF0q5K6162 ywjf7zcXMqx9U3D0wvge8YscwLu08ZEjoPw9vQxFzaT3BNUzEJ9Vw7xZjVb0+opSI6 A5YbdOiKZqNOq8VIOFh6Ib304NBtIrQaruL4tczO/pJysiKnfpj+ETJQz5kEGFd2Jp IVegqM+4QUUKdGgjDW7jfSEkGFuZe5HQSolx8ScwMpLBXkPh7eH9Vs0l+qf1qbXnFK /ulv9uGsVI0dcT2Y0nn/xJmPgjsQ/YIIKhGHrCH3c9DCegNMajwiEDjRutjwcEySEk f9Z8y0RuZY+Vg== Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 171CB1200043; Fri, 14 Feb 2025 06:14:41 -0500 (EST) Received: from phl-imap-12 ([10.202.2.86]) by phl-compute-10.internal (MEProxy); Fri, 14 Feb 2025 06:14:41 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegleehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtgfesthejredtredt tdenucfhrhhomhepfdfnvghonhcutfhomhgrnhhovhhskhihfdcuoehlvghonheskhgvrh hnvghlrdhorhhgqeenucggtffrrghtthgvrhhnpeejvefflefgledvgfevvdetleehhfdv ffehgeffkeevleeiveefjeetieelueeuvdenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehlvghonhdomhgvshhmthhprghuthhhphgvrhhsohhn rghlihhthidquddvfedtheefleekgedqvdejjeeljeejvdekqdhlvghonheppehkvghrnh gvlhdrohhrgheslhgvohhnrdhnuhdpnhgspghrtghpthhtohepvdeipdhmohguvgepshhm thhpohhuthdprhgtphhtthhopegrhihushhhrdhsrgifrghlsegthhgvlhhsihhordgtoh hmpdhrtghpthhtohepsghhrghrrghtsegthhgvlhhsihhordgtohhmpdhrtghpthhtohep lhhouhhishdrphgvvghnshestghorhhighhinhgvrdgtohhmpdhrtghpthhtohepohhssh dqughrihhvvghrshestghorhhighhinhgvrdgtohhmpdhrtghpthhtohephhgvrhgsvghr thesghhonhguohhrrdgrphgrnhgrrdhorhhgrdgruhdprhgtphhtthhopegvughumhgrii gvthesghhoohhglhgvrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrlhdrnhhguhih vghnsehinhhtvghlrdgtohhmpdhrtghpthhtohepphhriigvmhihshhlrgifrdhkihhtsh iivghlsehinhhtvghlrdgtohhmpdhrtghpthhtohepjhhvsehjvhhoshgsuhhrghhhrdhn vght X-ME-Proxy: Feedback-ID: i927946fb:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id DF44F1C20066; Fri, 14 Feb 2025 06:14:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Fri, 14 Feb 2025 13:14:21 +0200 From: "Leon Romanovsky" To: "Steffen Klassert" Cc: "Andrew Lunn" , "Ayush Sawal" , "Bharat Bhushan" , "Eric Dumazet" , "Geetha sowjanya" , hariprasad , "Herbert Xu" , intel-wired-lan@lists.osuosl.org, "Jakub Kicinski" , "Jay Vosburgh" , "Jonathan Corbet" , linux-doc@vger.kernel.org, linux-rdma@vger.kernel.org, "Louis Peens" , netdev@vger.kernel.org, oss-drivers@corigine.com, "Paolo Abeni" , "Potnuri Bharat Teja" , "Przemek Kitszel" , "Saeed Mahameed" , "Subbaraya Sundeep" , "Sunil Goutham" , "Tariq Toukan" , "Tony Nguyen" , "Ilia Lin" Message-Id: In-Reply-To: References: <20250212183020.GJ17863@unreal> Subject: Re: [PATCH ipsec-next 2/5] xfrm: simplify SA initialization routine Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, Feb 14, 2025, at 11:29, Steffen Klassert wrote: > On Wed, Feb 12, 2025 at 08:30:20PM +0200, Leon Romanovsky wrote: >> On Wed, Feb 12, 2025 at 12:56:48PM +0100, Steffen Klassert wrote: >> > On Wed, Feb 05, 2025 at 08:20:21PM +0200, Leon Romanovsky wrote: >> > > From: Leon Romanovsky >> > > >> > > SA replay mode is initialized differently for user-space and >> > > kernel-space users, but the call to xfrm_init_replay() existed in >> > > common path with boolean protection. That caused to situation where >> > > we have two different function orders. >> > > >> > > So let's rewrite the SA initialization flow to have same order for >> > > both in-kernel and user-space callers. >> > > >> > > Signed-off-by: Leon Romanovsky >> > > --- >> > > include/net/xfrm.h | 3 +-- >> > > net/xfrm/xfrm_state.c | 22 ++++++++++------------ >> > > net/xfrm/xfrm_user.c | 2 +- >> > > 3 files changed, 12 insertions(+), 15 deletions(-) >> > > >> > > diff --git a/include/net/xfrm.h b/include/net/xfrm.h >> > > index 28355a5be5b9..58f8f7661ec4 100644 >> > > --- a/include/net/xfrm.h >> > > +++ b/include/net/xfrm.h >> > > @@ -1770,8 +1770,7 @@ void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si); >> > > u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq); >> > > int xfrm_init_replay(struct xfrm_state *x, struct netlink_ext_ack *extack); >> > > u32 xfrm_state_mtu(struct xfrm_state *x, int mtu); >> > > -int __xfrm_init_state(struct xfrm_state *x, bool init_replay, >> > > - struct netlink_ext_ack *extack); >> > > +int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack); >> > > int xfrm_init_state(struct xfrm_state *x); >> > > int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type); >> > > int xfrm_input_resume(struct sk_buff *skb, int nexthdr); >> > > diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c >> > > index 568fe8df7741..42799b0946a3 100644 >> > > --- a/net/xfrm/xfrm_state.c >> > > +++ b/net/xfrm/xfrm_state.c >> > > @@ -3120,8 +3120,7 @@ u32 xfrm_state_mtu(struct xfrm_state *x, int mtu) >> > > } >> > > EXPORT_SYMBOL_GPL(xfrm_state_mtu); >> > > >> > > -int __xfrm_init_state(struct xfrm_state *x, bool init_replay, >> > > - struct netlink_ext_ack *extack) >> > > +int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack) >> > >> > The whole point of having __xfrm_init_state was to >> > sepatate codepaths that need init_replay and those >> > who don't need it. That was a bandaid for something, >> > unfortunately I don't remenber for what. >> > >> > If we don't need that anymore, maybe we can merge >> > __xfrm_init_state into xfrm_init_state, as it was >> > before. >> >> Main difference between __xfrm_init_state and xfrm_init_state is that >> latter is called without extack, which doesn't exist in kernel path. > > That split happened ~ 15 years ago, we did not have extack back than. > But I'm also ok with keeping it if extack is a reason for it. > > Do you plan to respin, or should I take the patchset as is? The best way will be if you can take this series as is. > > Thanks!