Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: kuniyu@google.com
Cc: edumazet@kernel.org, ncardwell@google.com, davem@davemloft.net,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	kuni1840@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH v1 net-next 1/8] tcp: Clean up the first loop in tcp_collapse().
Date: Sun, 15 Nov 2026 04:10:50 +0000	[thread overview]
Message-ID: <179471585026.2199510.8755335400317906663@kernel.org> (raw)
In-Reply-To: <20261114040101.1043546-2-kuniyu@google.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The patch is titled a clean-up, and its message presents the
  change as equivalent to the old code ("If we goto skip_this in both…

--

tcp: Clean up the first loop in tcp_collapse().

This commit restructures the first loop of tcp_collapse(). The SYN/FIN
and skb_frags_readable() checks are folded into one goto skip_this test,
and the end_of_skbs flag is replaced with the inverted loop condition.
It also moves the readability check after the fully overlapping check.

> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index a2074a1af4222..32e63d089db89 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5839,23 +5839,17 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,

[ ... ]

>  restart:
> -	for (end_of_skbs = true; skb != NULL && skb != tail; skb = n) {
> +	for (; skb && skb != tail; skb = n) {
>  		n = tcp_skb_next(skb, list);
>  
> -		if (!skb_frags_readable(skb))
> -			goto skip_this;
> -
>  		/* No new bits? It is possible on ofo queue. */
>  		if (!before(start, TCP_SKB_CB(skb)->end_seq)) {
>  			skb = tcp_collapse_one(sk, skb, list, root);
> -			if (!skb)
> -				break;
>  			goto restart;
>  		}
>  
> @@ -5864,27 +5858,25 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
>  		 * - bloated or contains data before "start" or
>  		 *   overlaps to the next one and mptcp allow collapsing.
>  		 */
> -		if (!(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) &&
> -		    (tcp_win_from_space(sk, skb->truesize) > skb->len ||
> -		     before(TCP_SKB_CB(skb)->seq, start))) {
> -			end_of_skbs = false;
> +		if (!skb_frags_readable(skb) ||
> +		    TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN))
> +			goto skip_this;

[Severity: Low]
The commit message describes this as an equivalent clean-up:

  If we goto skip_this in both cases, we can remove the second
  tests and simply replace end_of_skbs with the inverted loop
  condition.

Is that true for SYN/FIN skbs? Before this patch, take a SYN or FIN skb
whose readable successor n overlaps it and is allowed by
tcp_skb_can_collapse_rx(). That skb reached the second break with
end_of_skbs = false:

	if (n && n != tail && skb_frags_readable(n) &&
	    tcp_skb_can_collapse_rx(skb, n) &&
	    TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(n)->seq) {
		end_of_skbs = false;
		break;
	}

The post-loop test then returned early:

	if (end_of_skbs ||
	    (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) ||
	    !skb_frags_readable(skb))
		return;

So nothing in the head..tail range was collapsed in that call. The
post-loop SYN/FIN test was not redundant.

With this patch every SYN/FIN skb goes to skip_this. start advances and
scanning continues, so later skbs in the same range can now be collapsed.
A peer can reach this path, for example with a FIN segment followed by an
overlapping segment in the ofo queue.

The readability reordering also changes behaviour. Unreadable (devmem)
skbs that lie entirely below start used to be skipped. Now they are
unlinked and freed by tcp_collapse_one(), which also increments
LINUX_MIB_TCPRCVCOLLAPSED. The message only says:

  Also, skb_frags_readable() should be tested after the fully
  overlapping check.

It gives no reason for the change.

The new behaviour looks safe as far as I can tell. The copy loop still
stops at SYN/FIN skbs, and offset stays non-negative.

Could the changelog state both the SYN/FIN change and the devmem change
explicitly, rather than presenting the patch as a pure clean-up? The first
loop at the end of the series still behaves this way, so this patch looks
like the right place to describe it.

> +
> +		if (tcp_win_from_space(sk, skb->truesize) > skb->len ||
> +		    before(TCP_SKB_CB(skb)->seq, start))
>  			break;
> -		}

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261114040101.1043546-1-kuniyu%40google.com

  parent reply	other threads:[~2026-11-15  4:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14  4:00 [PATCH v1 net-next 0/8] tcp: Prevent tcp_collapse() from bloating queue Kuniyuki Iwashima
2026-11-14  4:00 ` [PATCH v1 net-next 1/8] tcp: Clean up the first loop in tcp_collapse() Kuniyuki Iwashima
2026-11-14 15:32   ` Eric Dumazet
2026-11-14 16:07     ` Kuniyuki Iwashima
2026-11-15  4:10   ` netdev-bot+sashiko [this message]
2026-11-14  4:00 ` [PATCH v1 net-next 2/8] tcp: Don't collapse high density skb Kuniyuki Iwashima
2026-11-14 15:33   ` Eric Dumazet
2026-11-14  4:00 ` [PATCH v1 net-next 3/8] tcp: Stop collapsing if not bloated Kuniyuki Iwashima
2026-11-14 15:35   ` Eric Dumazet
2026-11-15  4:10   ` netdev-bot+sashiko
2026-11-14  4:00 ` [PATCH v1 net-next 4/8] net: Move SKB_SMALL_HEAD_CACHE_SIZE to skbuff.h Kuniyuki Iwashima
2026-11-14  4:00 ` [PATCH v1 net-next 5/8] tcp: Skip collapsing if collapsed skb is less-dense Kuniyuki Iwashima
2026-11-14 15:36   ` Eric Dumazet
2026-11-14 16:18     ` Kuniyuki Iwashima
2026-11-14  4:00 ` [PATCH v1 net-next 6/8] tcp: Allocate all new skb before collapsing Kuniyuki Iwashima
2026-11-14 15:37   ` Eric Dumazet
2026-11-15  4:10   ` netdev-bot+sashiko
2026-11-14  4:00 ` [PATCH v1 net-next 7/8] tcp: Batch memory accounting in tcp_collapse() Kuniyuki Iwashima
2026-11-14 15:38   ` Eric Dumazet
2026-11-14  4:00 ` [PATCH v1 net-next 8/8] selftest: packetdrill: Add test for tcp_collapse() Kuniyuki Iwashima
2026-11-14 15:39   ` Eric Dumazet
2026-11-14 16:20     ` Kuniyuki Iwashima
2026-11-15  4:10   ` netdev-bot+sashiko
2026-11-14 15:31 ` [PATCH v1 net-next 0/8] tcp: Prevent tcp_collapse() from bloating queue Eric Dumazet
2026-11-14 16:06   ` Kuniyuki Iwashima

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=179471585026.2199510.8755335400317906663@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuni1840@gmail.com \
    --cc=kuniyu@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox