From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) (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 061B236C9EE for ; Fri, 8 May 2026 07:59:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778227145; cv=none; b=ETD+mud7Ibz/k1XefCW6XDvQd826DPIhRCqqWk0EZhP2il4Fh5GH05dITh5t2RAGP3Pv3f2nvOsHYsE1CUWpVPAgc4H8atYCto5eJ1nuo9KJrMwvSebv6Sc8NJ+lFTlTIbWQ/jpVmFc7bHg1NdlsV24BtQN8St7gtL5eL56rkjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778227145; c=relaxed/simple; bh=A5eLo0k1WN3dKsNjpIfOF2pKn7Y3GKqYof0joQHkltM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tupLO7whc3FBqAjyafTPyAj2pTzyBEL7XnzJfAIrG8ddxK53KiMRo0J+XxpzTrMiuZUMda3UE9iyZWx6O+Jw620NSWzdgeCZovhV0wdw44RtiiLznC5omHB/9btxodSVZXzXdLLzEoA5gIJdDXE71hhY2dRK7UMrl6VoQzVKYPc= 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=Qjy8dFfX; arc=none smtp.client-ip=95.215.58.177 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="Qjy8dFfX" Message-ID: <6a1a50d1-9aa8-406d-90b1-4d5ca9fe0afb@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778227141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EebeowThzEPHzOPHxVe8PsQqS05P87lAK1+IwQ9r900=; b=Qjy8dFfXevjzgSXdRI1yDAk2G8yPi/JugjEL0KTVbj7Q73qdGyrgbj7Ldy7OqgADZFF+ct MhgQ+ysmCiE64X077RZfXX4MGsixZdjmO3BmUT3YT//HVjGBsu6ZI1HZsZtfKDPVzSroHW I/Q0TdE6vWkf3MuGkDwmsBElASIklS0= Date: Fri, 8 May 2026 15:58:34 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net v2] rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present To: Hyunwoo Kim , dhowells@redhat.com, marc.dionne@auristor.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, qingfang.deng@linux.dev Cc: linux-afs@lists.infradead.org, netdev@vger.kernel.org, stable@vger.kernel.org References: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 5/8/26 2:42 PM, Hyunwoo Kim wrote: > The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE > handler in rxrpc_verify_response() copy the skb to a linear one before > calling into the security ops only when skb_cloned() is true. An skb > that is not cloned but still carries paged fragments (skb->data_len != 0) > falls through to the in-place decryption path, which binds the frag > pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). > > Extend the gate so that any skb with non-linear data is also copied, > ensuring the security handler always operates on a fully linear skb. > The OOM/trace handling already in place is reused. > > Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") > Cc: stable@vger.kernel.org > Signed-off-by: Hyunwoo Kim > --- > Changes in v2: > - Use skb_is_nonlinear() instead of skb->data_len > - v1: https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/ > --- > net/rxrpc/call_event.c | 2 +- > net/rxrpc/conn_event.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c > index fdd683261226..a6ad5ff6ec5f 100644 > --- a/net/rxrpc/call_event.c > +++ b/net/rxrpc/call_event.c > @@ -334,7 +334,7 @@ bool rxrpc_input_call_event(struct rxrpc_call *call) > > if (sp->hdr.type == RXRPC_PACKET_TYPE_DATA && > sp->hdr.securityIndex != 0 && > - skb_cloned(skb)) { > + (skb_cloned(skb) || skb_is_nonlinear(skb))) { > /* Unshare the packet so that it can be > * modified by in-place decryption. > */ > diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c > index a2130d25aaa9..632cbeff1f5d 100644 > --- a/net/rxrpc/conn_event.c > +++ b/net/rxrpc/conn_event.c > @@ -245,7 +245,7 @@ static int rxrpc_verify_response(struct rxrpc_connection *conn, > { > int ret; > > - if (skb_cloned(skb)) { > + if (skb_cloned(skb) || skb_is_nonlinear(skb)) { > /* Copy the packet if shared so that we can do in-place > * decryption. > */ Why not adopt the same gate as the ESP fix:     skb_cloned(skb) || skb_has_frag_list(skb) || skb_has_shared_frag(skb) so NIC page_pool RX keeps its zero-copy path while still catching the splice-loopback vector?