From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (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 67A1D40B0FE for ; Thu, 24 Sep 2026 08:11:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790237511; cv=none; b=Jlpk78ktgL0N5AIfRmwp/LAsiiypOIgFNFo6opMUM9HgDQ1LpMk/SwpOs6cGvpRXiOPJ8+zngklu3kaAXi6n1P7vvxhFlwPpMtHfn7zzPe9pYVdKU+aU2haaLDaOE2KBXywLV/UeqOmtQWsqsLAFWjXHpUHACPFKsS4epOS4Ok8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790237511; c=relaxed/simple; bh=DpbisNFop2DM9nFw1hD/w3CTU5u1md8DAi8kE2Bk3z8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cLWFSVNLFb71x7pNMqzo2FHPMA7bDobHuJnA3Ds4dkWurVyMbEWm82EzM3xW7mx0p4IvaIvYcTjMxwTvB3C6izMOQPbpT6aWv0qFPyhHMEIa0MriEbwMO/K4PcTQBHrlIRIIT0Zw9SyuIfJ7DZ8VbM2EonjTMWfYWAq00GZVSQY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=KrodUWpY; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="KrodUWpY" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=DpbisNFop2DM9nFw1hD/w3CTU5u1md8DAi8kE2Bk3z8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790237507; v=1; x=1790842307; b=KrodUWpYqx14daR0Ng2SfGa2ZnZup0wM1A5gp93hmmjfQcy6irEsnau9uZJjgeo/TMeaU8Ff BRajS1F0CE8oE1MkYApluxi6yjICwaCfc3fRf8OO0femu3u7+qQRBSmINL5MU849lDrIraAzkcE A2NDgYePvz9GYW/Becyh2QMo= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta10.migadu.com with ESMTPS id efc2c0001f259c1f; Thu, 24 Sep 2026 08:11:47 +0000 X-Mizu-Trace-ID: efc2c0001f259c1f X-Migadu-Flow: FLOW_OUT Date: Thu, 24 Sep 2026 16:11:37 +0800 From: Hangbin Liu To: Andrea Mayer Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Hangbin Liu , stefano.salsano@uniroma2.it Subject: Re: [PATCH net-next 1/5] seg6: split final End process out of flavor processing Message-ID: References: <20260922-srv6_flavors_endx-v1-0-4d01c05c47b7@kylinos.cn> <20260922-srv6_flavors_endx-v1-1-4d01c05c47b7@kylinos.cn> <20260923134637.4e56d6c422e3f89dd17f4a63@uniroma2.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260923134637.4e56d6c422e3f89dd17f4a63@uniroma2.it> On Wed, Sep 23, 2026 at 01:46:37PM +0200, Andrea Mayer wrote: > > @@ -829,7 +830,10 @@ static int input_action_end(struct sk_buff *skb, struct seg6_local_lwt *slwt) > > * information extracted from the packet, e.g. presence/absence of SRH, > > * Segment Left = 0, etc. > > */ > > - return end_flv8986_core(skb, slwt); > > + ret = end_flv8986_core(skb, slwt); > > + if (ret) > > + return ret; > > A nit: a blank line before the final return would match the rest of > the file. OK > > > + return input_action_end_finish(skb, slwt); > > } > > This changes the semantics of end_flv8986_core(): it no longer > forwards the packet, it only processes it, and the caller does the > finish step. Is it worth saying so in a comment above the function? A > future caller that misses it would leak the skb. I will add a comment for the function change. > > A heads-up: reviewing this made me notice that a fix I have pending > for net touches these same lines. It makes the skb data writable > before advance_nextseg() modifies Segments Left and the IPv6 > destination address, since today a clone sees the change. > It also turns the "kfree_skb(skb); return -EINVAL;" right below into > kfree_skb_reason(). Since it goes through net, this hunk may need a > rebase once net is merged back into net-next. Sure, I will do rebase once it merged to net-next. Thanks Hangbin