All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antony Antony <antony@phenome.org>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netdev@vger.kernel.org, chopps@labn.net, horms@kernel.org,
	pabeni@redhat.com, kuba@kernel.org, edumazet@google.com,
	davem@davemloft.net, herbert@gondor.apana.org.au,
	steffen.klassert@secunet.com, Hao Long <me@imlonghao.com>
Subject: Re: [PATCH ipsec v2] xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly
Date: Mon, 9 Mar 2026 18:37:04 +0100	[thread overview]
Message-ID: <aa8FQEdKU9lNnGDv@Antony2201.local> (raw)
In-Reply-To: <20260304140935.19783-1-fmancera@suse.de>

On Wed, Mar 04, 2026 at 03:09:35PM +0100, Fernando Fernandez Mancera wrote:
> In iptfs_reassem_cont(), IP-TFS attempts to append data to the new inner
> packet 'newskb' that is being reassembled. First a zero-copy approach is
> tried if it succeeds then newskb becomes non-linear.
> 
> When a subsequent fragment in the same datagram does not meet the
> fast-path conditions, a memory copy is performed. It calls skb_put() to
> append the data and as newskb is non-linear it triggers
> SKB_LINEAR_ASSERT check.

I wonder if linearizing has a performance penalty? Did you test that?

I tried to reproduce it but had no luck so far. It seems the NICs I tested,
CX4 and virtio, veth, deliver the inner packet as a linear skb.

Any tricks to force Mellanox CX4 and virtio to deliver
non-linear skbs?

-antony

> 
>  Oops: invalid opcode: 0000 [#1] SMP NOPTI
>  [...]
>  RIP: 0010:skb_put+0x3c/0x40
>  [...]
>  Call Trace:
>   <IRQ>
>   iptfs_reassem_cont+0x1ab/0x5e0 [xfrm_iptfs]
>   iptfs_input_ordered+0x2af/0x380 [xfrm_iptfs]
>   iptfs_input+0x122/0x3e0 [xfrm_iptfs]
>   xfrm_input+0x91e/0x1a50
>   xfrm4_esp_rcv+0x3a/0x110
>   ip_protocol_deliver_rcu+0x1d7/0x1f0
>   ip_local_deliver_finish+0xbe/0x1e0
>   __netif_receive_skb_core.constprop.0+0xb56/0x1120
>   __netif_receive_skb_list_core+0x133/0x2b0
>   netif_receive_skb_list_internal+0x1ff/0x3f0
>   napi_complete_done+0x81/0x220
>   virtnet_poll+0x9d6/0x116e [virtio_net]
>   __napi_poll.constprop.0+0x2b/0x270
>   net_rx_action+0x162/0x360
>   handle_softirqs+0xdc/0x510
>   __irq_exit_rcu+0xe7/0x110
>   irq_exit_rcu+0xe/0x20
>   common_interrupt+0x85/0xa0
>   </IRQ>
>   <TASK>
> 
> Fix this by checking if the skb is non-linear. If it is, linearize it by
> calling skb_linearize(). As the initial allocation of newskb originally
> reserved enough tailroom for the entire reassembled packet we do not
> need to check if we have enough tailroom or extend it.
> 
> Fixes: 5f2b6a909574 ("xfrm: iptfs: add skb-fragment sharing code")
> Reported-by: Hao Long <me@imlonghao.com>
> Closes: https://lore.kernel.org/netdev/DGRCO9SL0T5U.JTINSHJQ9KPK@imlonghao.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> v2: adjusted fixes tag and dropped skb_is_nonlinear() as skb_linearize()
> is enough.
> ---
>  net/xfrm/xfrm_iptfs.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
> index 050a82101ca5..c96bec84bfa6 100644
> --- a/net/xfrm/xfrm_iptfs.c
> +++ b/net/xfrm/xfrm_iptfs.c
> @@ -901,6 +901,12 @@ static u32 iptfs_reassem_cont(struct xfrm_iptfs_data *xtfs, u64 seq,
>  	    iptfs_skb_can_add_frags(newskb, fragwalk, data, copylen)) {
>  		iptfs_skb_add_frags(newskb, fragwalk, data, copylen);
>  	} else {
> +		if (skb_linearize(newskb)) {
> +			XFRM_INC_STATS(xs_net(xtfs->x),
> +				       LINUX_MIB_XFRMINBUFFERERROR);
> +			goto abandon;
> +		}
> +
>  		/* copy fragment data into newskb */
>  		if (skb_copy_seq_read(st, data, skb_put(newskb, copylen),
>  				      copylen)) {
> -- 
> 2.53.0
> 
> 


  reply	other threads:[~2026-03-09 17:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04 14:09 [PATCH ipsec v2] xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly Fernando Fernandez Mancera
2026-03-09 17:37 ` Antony Antony [this message]
2026-03-10  9:48   ` Fernando Fernandez Mancera
2026-03-10 17:26     ` Antony Antony
2026-03-10 12:21 ` Steffen Klassert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa8FQEdKU9lNnGDv@Antony2201.local \
    --to=antony@phenome.org \
    --cc=chopps@labn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=me@imlonghao.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.