All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Simon Baatz via B4 Relay <devnull+gmbnomis.gmail.com@kernel.org>,
	Eric Dumazet <edumazet@google.com>
Cc: gmbnomis@gmail.com, Neal Cardwell <ncardwell@google.com>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
Date: Fri, 12 Jun 2026 15:43:55 -0700	[thread overview]
Message-ID: <20260612154355.37bb426d@kernel.org> (raw)
In-Reply-To: <20260610-tcp_fin_more_restrictive-v1-1-eefc30d7ddd8@gmail.com>

On Wed, 10 Jun 2026 00:09:24 +0200 Simon Baatz via B4 Relay wrote:
> From: Simon Baatz <gmbnomis@gmail.com>
> 
> Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
> RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
> exception in tcp_data_queue(), which accepts bare in-order FINs even
> when the advertised window is zero. That behavior is not
> RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
> bare FIN packets under memory pressure") to break tight FIN/ACK loops
> caused by broken clients.
> 
> However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
> acceptance of FIN packets when RWIN is 0") is broader than required
> and allows other non-compliant packets as well.
> 
> Tighten the tcp_sequence() FIN exception to only allow packets where
> the packet is a bare in-order FIN and only the FIN flag extends beyond
> tcp_max_receive_window(). In particular, this exception is only
> reachable if tcp_max_receive_window() is zero. Otherwise the packet is
> already accepted by the normal sequence check.
> 
> The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
> behavior already and does not need to be changed.
> 
> Signed-off-by: Simon Baatz <gmbnomis@gmail.com>

This is odd. You are sending this patch which shares a lot of
similarities with Eric's patch:
https://lore.kernel.org/all/20260608151452.706822-1-edumazet@google.com/

Why are you submitting your own patch instead of discussing it further
with Eric and letting him send v2?

Eric, how would you like to proceed?

  reply	other threads:[~2026-06-12 22:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09 22:09 [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence() Simon Baatz via B4 Relay
2026-06-09 22:09 ` Simon Baatz
2026-06-12 22:43 ` Jakub Kicinski [this message]
2026-06-12 23:40   ` Simon Baatz
2026-06-13  3:47     ` Eric Dumazet

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=20260612154355.37bb426d@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devnull+gmbnomis.gmail.com@kernel.org \
    --cc=edumazet@google.com \
    --cc=gmbnomis@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.