From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 AA788330D23 for ; Mon, 23 Feb 2026 17:16:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771867002; cv=none; b=VIEScWm2i8yD8CMWGCiAHkWvq4P+Oei2L27lfKMtVvEbRMSIjXX6qITDgNatbZdIJvYQE581z3um34IrRzIUN1ehfCnjq0EdawlD1IYyIdjsVAR4Rj2F6R7zooF8j6RFPJVH3y8vwZ5WJrm8m2VgHNqtKP7YDdQHxfhnuL5r1ps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771867002; c=relaxed/simple; bh=BzKwdlyoAEssFRnM96qoS8PG4Ad9xyev/bf3EqhCekU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KBOYa3nbT49A6RyhBgGGK0QtK94Td/FqCiz7VYVg2VF0WvDulMfu3VlOC5V755iVTzgnvzT+A8ki0yFEr7KRktyF1pAm9ft/I4gR0VJ8zUXdJlwmIQKiVBRWoXx0FlwHHZ4cHf9SQbAAUZVriv8/DoatvVvGHF7eJwLDs8pUVvk= 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=L2RRAXOP; arc=none smtp.client-ip=209.85.128.45 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="L2RRAXOP" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48336a6e932so28349655e9.3 for ; Mon, 23 Feb 2026 09:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771866999; x=1772471799; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jblqPpeSoB/tKv9xpHVL5Qn7LqWC4JDIrbkAXoIweZ4=; b=L2RRAXOPg0Z6gKj6fpDDFKPt7Pguj0GyLAHd1t8SOGIzaQIdJqebPfRqrwjL9M42iu psliNGDQdS9R1IQFlB8hdr6b66I5hWSVkH8zNak7ojXt84mHFv0FPqABVQn6TaIlpfVK vbWmRyv86u2GTkU80YDNylVAU+AQlwSJg/NaocSLzmDD4eUIDcODOvPW/F4dvQdrbXUo Ho+3w/jIg+97Oc3+AgblNg9me0HShQoHzHNbDPRlZgoy4eohMjKE1KK9RsLnN/r51GBa ZfwKCi49jgQAD5mv+cKdIsWInjjUxl6cNxVZihXw8rsuvdcHvNDD0xLHaYv4ytOYRfHB F+Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771866999; x=1772471799; h=in-reply-to: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=jblqPpeSoB/tKv9xpHVL5Qn7LqWC4JDIrbkAXoIweZ4=; b=KKjdzr6JfebVWHsHdChdPANnp9L0P9lCiEwazBhImmNbxmPKGtH/iGGDIVucmXVM/h jro2MB4tiw9pRw7Mx+81RhUEsviQisSNN/hsX5JIp7ZQ9bV3f16hQ6u8ffq6fmKt6Ngk PiyDSHpSbOeNnyMVKVLNOUDIhZr9SKxJ0cmeTTNgPUsXSofuR46TuQxq+2+IumybcTIw kTLZwzznd1klPlW90LhFFErRgOIzM9Q05Myqr5k+i1ZY8UzWi82IONE0IjzQmqw8F6ei xYpZwOxS//8Hf0ArFiD5Kz+mEFSZjPTh3N+cCtv50DI1g3Xr/MtNtTjX/gyn4AQx6jMi uqjA== X-Forwarded-Encrypted: i=1; AJvYcCXXLA+A1iXAdRJcyuj4Mzi65B8tKLHXpnGxlwIIKUUERv4KcavoxICF3JU4Mzn/gZj8Slrv3bx1eCpSBQQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxAhw1kucJctX/zlsxIlN/qRZ2jdHNm901cU/+CYnZ4HweiWbc6 xbfAQ91NZDDT/tiO8TL8cOKWSRc1GTZZ/qYvzSyucV+POfj+LK8SXUZJ X-Gm-Gg: AZuq6aLV6XcjdcEn3BS+PKZxjv1vjRSFS7ZQ+bjJacbnjCRNNjQrlbKdjg8l6V4omEU NHFZ8AzM8V6nG7CzAmNwqjl10Mc0NmSrl07WFohb3eLlBkpfd+f/3EuQQr3JBGfNsNpC+DEhpiL itlAQfrRlMLDlNa62Wm/wrWFgSVN7IFGt+A8+e4wGXF+FueOKgY1K20hBtaOks/wRUisn73htp7 5L8VByA3706R5hK7EJCC+o+4hzPVVWt9SrCUStJKrgrbPrmWYlLC1oJDocI9XAFZk0qNaQIQB5+ end3odjD2ygRr5/vGfQTrbZyMfP5Aibvy5oJJmN2Td+oe9Vsw9X3KskhxBlZPPyfPow9Tr3Itkm OZa9rjtMD+Oep5ZQIFPpsyWhWA1pUFjH9B/Cgtf5HrvgyixTFMhne7Hmcqol7sIodUHmrghS+u/ JMmmyQK1s3KwoP05FxX7c+t7uMMT4Evacg3dfn/mWHJGegpCEH5zOyHWHbMbiPjg== X-Received: by 2002:a05:600c:848e:b0:483:71f7:2797 with SMTP id 5b1f17b1804b1-483a9608834mr171406645e9.14.1771866998812; Mon, 23 Feb 2026 09:16:38 -0800 (PST) Received: from gandalf.schnuecks.de (p5b2e2ef5.dip0.t-ipconnect.de. [91.46.46.245]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a4e8d392sm248277725e9.2.2026.02.23.09.16.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 09:16:38 -0800 (PST) Received: by gandalf.schnuecks.de (Postfix, from userid 500) id 844232FD9CF7; Mon, 23 Feb 2026 18:16:37 +0100 (CET) Date: Mon, 23 Feb 2026 18:16:37 +0100 From: Simon Baatz To: Eric Dumazet Cc: Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH net 1/2] tcp: re-enable acceptance of FIN packets when RWIN is 0 Message-ID: References: <20260222-fix_zero_wnd_fin-v1-0-5f4034952f3c@gmail.com> <20260222-fix_zero_wnd_fin-v1-1-5f4034952f3c@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=us-ascii Content-Disposition: inline In-Reply-To: Hi Eric, On Mon, Feb 23, 2026 at 09:36:38AM +0100, Eric Dumazet wrote: > On Mon, Feb 23, 2026 at 9:01???AM Eric Dumazet wrote: > ... > > > > > > Fixes: 9ca48d616ed7 ("tcp: do not accept packets beyond window") > > > > OK, but this commit is fine ? It seems the issue is coming from buggy peers ? That "Fixes" tag is a technicality, I did not want to imply that the commit is broken: 9ca48d616ed7 (which is RFC compliant) turns the workaround (which isn't RFC compliant) 2bd99aef1b19 ("tcp: accept bare FIN packets under memory pressure") into dead code. If we still need that workaround, technically, this is a regression caused by 9ca48d616ed7. If not, I am perfectly happy to propose a commit that removes the dead code. > > Eventually the receive queue would be drained by the application, the > > peer would retransmit > > this FIN, and it would be accepted. If I understand the problem correctly, the workaround was introduced to break a FIN/ACK loop because the broken peer (macOS) did not use exponential backoff in that scenario. So yes, it would be accepted, but until then we and the peer would ping-pong FIN/ACKs. But as said, if we don't need the workaround I can submit a patch to remove it. > ... > > > + reason = tcp_sequence(sk, TCP_SKB_CB(skb)->seq, > > > + TCP_SKB_CB(skb)->end_seq - th->fin); > > > > I don't think this is the right fix. Basically it says that FIN do not > > count, but TCP RFC says otherwise. We can be more specific and only allow that if we have a zero window. (I thought I would not hurt much to accept that FIN which does not take up real space) > > It also adds code in TCP fast path. Hmm, the call site for tcp_validate_incoming() in tcp_rcv_established() is: /* * Standard slow path. */ validate: if (!tcp_validate_incoming(sk, skb, th, 1)) return; Am I missing something? > We can keep fast path unchanged with this variant. > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index e7b41abb82aad33d8cab4fcfa989cc4771149b41..156c92450f3ed00357aff2ef3e586b83f3cecb5e > 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -4858,15 +4858,24 @@ static enum skb_drop_reason > tcp_disordered_ack_check(const struct sock *sk, > */ > > static enum skb_drop_reason tcp_sequence(const struct sock *sk, > - u32 seq, u32 end_seq) > + u32 seq, u32 end_seq, > + const struct tcphdr *th) > { > const struct tcp_sock *tp = tcp_sk(sk); > + u32 seq_limit; > > if (before(end_seq, tp->rcv_wup)) > return SKB_DROP_REASON_TCP_OLD_SEQUENCE; > > - if (after(end_seq, tp->rcv_nxt + tcp_receive_window(tp))) { > - if (after(seq, tp->rcv_nxt + tcp_receive_window(tp))) > + seq_limit = tp->rcv_nxt + tcp_receive_window(tp); > + if (unlikely(after(end_seq, seq_limit))) { > + /* Some stacks are known to handle FIN incorrectly; > allow the FIN > + * to extend beyond the window and check it in detail later. > + */ > + if (!after(end_seq - th->fin, seq_limit)) > + return SKB_NOT_DROPPED_YET; > + > + if (after(seq, seq_limit)) > return SKB_DROP_REASON_TCP_INVALID_SEQUENCE; > > /* Only accept this packet if receive queue is empty. */ > @@ -6379,7 +6388,8 @@ static bool tcp_validate_incoming(struct sock > *sk, struct sk_buff *skb, > > step1: > /* Step 1: check sequence number */ > - reason = tcp_sequence(sk, TCP_SKB_CB(skb)->seq, > TCP_SKB_CB(skb)->end_seq); > + reason = tcp_sequence(sk, TCP_SKB_CB(skb)->seq, > + TCP_SKB_CB(skb)->end_seq, th); > if (reason) { > /* RFC793, page 37: "In all states except SYN-SENT, all reset > * (RST) segments are validated by checking their SEQ-fields." Sure, I can do that. Do you want me to add the tcp_receive_window(tp) == 0 check to narrow it down further? (And a dumb question: As you are the author of that code, how do I attribute that commit when submitting a v2?)