From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 8737A17C203 for ; Mon, 4 May 2026 08:11:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777882279; cv=none; b=kg4VaiVOHERg1tXAr47YCYnvlfMx233DvP1BjN5ydk2VhEIZkxN/LGopagKBCga3j7X5vHJDfxB5jmIvkxyH2rDv1OS3iLSg9skzbwVxsEeaV6Bj0t8968NawCUk6+F313Ftc9ftZYuSb9gD4u74CJMxFYVY5pearNM3Wqb+O6o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777882279; c=relaxed/simple; bh=hBrj2lSJTLetwTP2wz6GowWY14Ggyw59DxllDhGpQHw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J9zCQSX5p2pZuJfD4eljJelbkIZJRR4ozve7pG7A1V5alHGD4WRZwksKzDG9VPGV5k+KB4Xn0/jdVlL0bT/L8ESMoUO3EYxRVpDEzicWN0GEcamSuCOiln+g0qQPKujxCqqaiNeO4CpwCMTR9O4Qpw6Wu6WoyuCPT3I1Gc7A5gs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Vvufxi4g; arc=none smtp.client-ip=209.85.216.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Vvufxi4g" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-358ed696623so1667658a91.0 for ; Mon, 04 May 2026 01:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777882278; x=1778487078; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=JMYtbUj01a1nUxyIuR4eIbeTRMLJqB5qPkqXXsohEzg=; b=Vvufxi4g+y3iSewiybyPuqLpxrlTUp2N+mSh//ua9ozm9Ltu7k+iSLzZOUzn6geVQH VDZO7aqvxvgJw5Mq0577iGaiQ4sfWaylCgn72Ab2VdsTQ0KhJAQTiiDIZWLyLOzhCJM1 dyGU3Mg5yudbdf8RicwHPGDiLCtLUAU4Q0H5QcW0KJuA+txKDVOTHWzpJv4QwK9WxLPj /sZy5z7SbIO8RMiqXpwh3Rs8nJVhGNyw8gOU32QkCZVKx2gDupazUSBV6w8XAJfiJ/QV J7+pvR6k7BTKc0UQub+8pwi5wNxMiQlz2AGZY852ZM7UZUWpIr6uI5l8dr++g9bgh6XQ sCbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777882278; x=1778487078; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JMYtbUj01a1nUxyIuR4eIbeTRMLJqB5qPkqXXsohEzg=; b=UGDJu4Ye7rXMasQ6ya/fXvP1YfOZRsAb0l2kY8sqzNEunSxZEBEgLXbE8BYkmTCL3O 0kIc0lbYSZzZbu9ENst4ShUnE2dXwtnU1McWN5nT7h8Ii+2mX0b4POrbX4yO1UznrwhK /kN+fUqgtx0d4MF+9j1xAXSKriAkN0vObFQkvzYTNKP4aEFgyOVMadAJD/vYRbh+LifG jCdXQngB/tf9k7fwfwPOoLlGxe8rmHTA9qUqUvNzPxGzEx4zS6FT9XlBQ/ct5L9PZLG6 PF9nNeeYbVujGlLHgUCVGHojP6ID9anPixzTLPLCb/iZReuL18cP1rQzZgOPgNrsyjaV pVbQ== X-Forwarded-Encrypted: i=1; AFNElJ9x0D0btMEBbhJ4H9sWj3TzeZ6B7zKpGQQtS2A25NwAJ1uW7X9bLbFXcw9HSvwvoUEVjnEHdNtVxSvqGoE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1PTAmU1tc0rPKPl/QzYwOop1aGt75tFRKXVgXR55H+1blx2jq CiD9iRbHG+obpUHYQCoCrxBCT/nlwqv8RjLYYx8ITD5D1513x25bCKpX X-Gm-Gg: AeBDieuBQxlA+Fs+L360Sjw2i+/R6n3ZeT060OlCN+lDQ12e6xReOXg8SLVFqVRFxDJ 3Be93T0ZXCxuZN5e1uDs+9PugaAqwXvW5o71mdAfkxubSkYyxtjMamQcyu3QIUd0v/Q95t0+lQQ EyxGmnbUPWcb4ns+LXjRIYuAr783L1LDw7FXfdoqvFVlLvRroT0Ez6x8Vl5evHqPb9yLPxZc48+ MP1rSbOKSOmZi0BHclL0vFM7ERCzh3jnCofFSGCgUCZ5xJ5S78ZXoloetLgNgNzWGTfaWxiN/Ym HHdxp/Bs2A2497jTx9IlYAfPLYpJl63LaAIIec4f1LBUOVKcxPsfDCqXC9MHs2N0jCJNva8s2M/ 1xJ5UVHxDwW1beODlirES5wyBXEg9TdJ3GfoevJS8n10ttGEq9waswNPk2egR0LZ1igoYf+OTih tBiN1W501IsRbZ/A7wKJ85SJxSfy7aAqVAtmeDYJXaOkhY0a0mLJnqLrmu7GoA0C3q X-Received: by 2002:a17:90a:2ce2:b0:365:46aa:e62e with SMTP id 98e67ed59e1d1-36546aaec0bmr1885640a91.24.1777882277739; Mon, 04 May 2026 01:11:17 -0700 (PDT) Received: from v4bel ([58.123.110.97]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-364dd3e9a3dsm11587831a91.16.2026.05.04.01.11.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2026 01:11:17 -0700 (PDT) Date: Mon, 4 May 2026 17:11:13 +0900 From: Hyunwoo Kim To: Steffen Klassert Cc: Eric Dumazet , HexRabbit , netdev@vger.kernel.org, Greg Kroah-Hartman , Herbert Xu , Simon Horman , "David S . Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Ido Schimmel , linux-kernel@vger.kernel.org, imv4bel@gmail.com Subject: Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags Message-ID: References: <20260504073403.38854-1-h3xrabbit@gmail.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, May 04, 2026 at 10:06:18AM +0200, Steffen Klassert wrote: > On Mon, May 04, 2026 at 12:56:50AM -0700, Eric Dumazet wrote: > > On Mon, May 4, 2026 at 12:53 AM Steffen Klassert > > wrote: > > > > > > We have antoher patch that addresses this issue in a different way, > > > so Cc the author of the other patch. > > > > > > On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote: > > > > From: Kuan-Ting Chen > > > > > > > > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP > > > > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), > > > > so later paths that may modify packet data can first make a private > > > > copy. The IPv4/IPv6 datagram append paths did not set this flag when > > > > splicing pages into UDP skbs. > > > > > > > > That leaves an ESP-in-UDP packet made from shared pipe pages looking > > > > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW > > > > fast path for uncloned skbs without a frag_list and decrypts in place > > > > over data that is not owned privately by the skb. > > > > > > > > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching > > > > TCP. Also make ESP input fall back to skb_cow_data() when the flag is > > > > present, so ESP does not decrypt externally backed frags in place. > > > > Private nonlinear skb frags still use the existing fast path. > > > > > > > > This intentionally does not change ESP output. In esp_output_head(), > > > > the path that appends the ESP trailer to existing skb tailroom without > > > > calling skb_cow_data() is not reachable for nonlinear skbs: > > > > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP > > > > tailen is positive. Thus ESP output will either use the separate > > > > destination-frag path or fall back to skb_cow_data(). > > > > > > > > Signed-off-by: Kuan-Ting Chen > > > > --- > > > > net/ipv4/esp4.c | 3 ++- > > > > net/ipv4/ip_output.c | 2 ++ > > > > net/ipv6/esp6.c | 3 ++- > > > > net/ipv6/ip6_output.c | 2 ++ > > > > 4 files changed, 8 insertions(+), 2 deletions(-) > > > > > > This looks ok to me. From the IPsec point of view, I'm > > > fine with this patch, but it also touches generic > > > networking code. So I'd like to hear an opinion of one > > > of the networking maintainers before proceeding. > > > > I have not seen a Fixes: tag. > > Right, we need a v2 with a Fixes tag, and maybe also > 'Cc: stable@vger.kernel.org' > > > Do we need to split this patch into two parts? > > I don't think we need to spilt it, we can merge it > either to the net or the ipsec tree. Both should > be OK. Also, please add: Reported-by: Hyunwoo Kim Best regards, Hyunwoo Kim