From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Zc00aNS3; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 67D365A0619 for ; Wed, 08 Oct 2025 12:01:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759917693; 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=6TtctwQIDLCf+osMv+dMsA6h86VFcuCEyCgRwmzmUwc=; b=Zc00aNS3cSvLbjyizYQu1gRMyxo7lmkMmGt95mp0zfdebNVZ4MYTbwGcnWi2+d5ldr53fb jbWvLftLbKqmJ5LExtoDtlPII+gkpY2vYZyD6nMtFrNaX8ediJxiIo9Hswoax00vgCBhg7 YEv9rbQfZNklH+KEIWk2GdK8QR6+oCo= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-299-4W8e7KeoNrSMjttuT_lqtA-1; Wed, 08 Oct 2025 06:01:31 -0400 X-MC-Unique: 4W8e7KeoNrSMjttuT_lqtA-1 X-Mimecast-MFC-AGG-ID: 4W8e7KeoNrSMjttuT_lqtA_1759917691 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3ece14b9231so3927200f8f.0 for ; Wed, 08 Oct 2025 03:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759917690; x=1760522490; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6TtctwQIDLCf+osMv+dMsA6h86VFcuCEyCgRwmzmUwc=; b=mgG8ZeiopZ7py1X5WjBdnxlwk7AD25pGs7JAgFJ2fxuPAOgPB01WS66PZyuUJnCHht mhE/ZyOwlCkTnYPMRk/ArN1CDKl3tBSlRjNnSK4NEy9Kr/8tf1h+hvmU/JxVk4TBwxzD xRqCHhaN9Fxa/DpjPXIeUjSuMVJtxMDPWrifwe/wmJtYzfMfZy0UoWPms6f23AW5eAos 2Ln7DH2j5N1WvVfIfx1m1Y2OKjQFL/247pun+2jmko1JQ4k4mv7xous6VTx8uI677rPI LMsH7Id71+2gze5W0UsHAYGEbWv7Eyl1s9xbZlB5vw7sp3m+bNBqsXtoD9KLH3WlhuhH eDFw== X-Gm-Message-State: AOJu0Ywt42uInIapT0SfOv9+VNTSgV0L3CT1RdbseMNF445oNUmEsq6/ FtPUBeYzdC0ZCAwFVOXW9XWokAPJdUJbC2n0xd4ChUD18KVnw3mj0Tl4TjWCdDmcvWqFRoCQ+F+ pUIKARXRVY/M3Vpiou/dLU/07zSBb08gTsFhksefSKLiCX9NaAn7IqlCqK+ZF3Q== X-Gm-Gg: ASbGncsPsDse2UOySwxwhLQoL6Yq6hqqztd/2PjNKbtmfe/NM6tJ2hT10MEYXS398zh iBvuD4J2+iXLWosjLhb6BPv8YN0dZODRvgHwYsQUz27bMiJcRLPCA9zPqAqGUEIvgWMs7q+2sQK 4+HHJkaAEP1q7OSKo55p7WCfCm1m3hmYjf62Xn4+1fDjIDhicYEkdAL/crgRE0i81T+0yPLtbr5 fr74+FQo3LFD3O0YgKAkQlnkRS3atfPo5rZT/Rjf33C90Vta2Tx8Bd68PaY2l95cl9mxMUJ0ZHt MXrjgOsbQv9nQ1Zm7qOGTGtXwlSeJuGHkgDcsYZ/eacvS6dQU88CO5Uv X-Received: by 2002:a05:600c:474d:b0:459:d451:3364 with SMTP id 5b1f17b1804b1-46fa9af81d5mr20562835e9.24.1759917690075; Wed, 08 Oct 2025 03:01:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGg3IKvl46st6q1HdvAPkhWVV3kKCvHgyhtWmCE4OFQoaOboErSnO0nReOptL+yzpx4lVstiQ== X-Received: by 2002:a05:600c:474d:b0:459:d451:3364 with SMTP id 5b1f17b1804b1-46fa9af81d5mr20562405e9.24.1759917689566; Wed, 08 Oct 2025 03:01:29 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4255d8ac750sm29498946f8f.24.2025.10.08.03.01.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Oct 2025 03:01:28 -0700 (PDT) Date: Wed, 8 Oct 2025 12:01:27 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 3/4] tcp: Don't consider FIN flags with mismatching sequence Message-ID: <20251008120127.75aa7585@elisabeth> In-Reply-To: References: <20251002000646.2136202-1-sbrivio@redhat.com> <20251002000646.2136202-4-sbrivio@redhat.com> <20251002135104.1a662029@elisabeth> <20251007003254.57ce5e26@elisabeth> <20251008004249.6dc894fa@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kdE3-U8h8k7XAN00ZiUaqaQtanGnSow_fPbs_qOI7Aw_1759917691 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: IBI4NS3ZCH5SMXCRWBMHQWX4JFO5RJHY X-Message-ID-Hash: IBI4NS3ZCH5SMXCRWBMHQWX4JFO5RJHY X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 8 Oct 2025 11:41:23 +1100 David Gibson wrote: > On Wed, Oct 08, 2025 at 12:42:49AM +0200, Stefano Brivio wrote: > > On Tue, 7 Oct 2025 10:34:01 +1100 > > David Gibson wrote: > > > On Tue, Oct 07, 2025 at 12:32:54AM +0200, Stefano Brivio wrote: > > > > On Fri, 3 Oct 2025 13:43:32 +1000 > > > > David Gibson wrote: > [snip] > > > > > @@ -1820,6 +1817,8 @@ static int tcp_data_from_tap(const struct ctx *c, struct tcp_tap_conn *conn, > > > > > break; > > > > > seq_from_tap += size; > > > > > iov_i += count; > > > > > + if (th->fin) > > > > > + fin = 1; > > > > > > > > > > if (keep == i) > > > > > keep = -1; > > > > > > > > > > > > > > > We'd need to double check that the "accept data segment" path is safe > > > > > with len == 0, of course. > > > > > > > > For sure it's not before d2c33f45f7be ("tcp: Convert > > > > tcp_data_from_tap() to use iov_tail"), because we might add > > > > zero-length segments to the tcp_iov array, and that would make > > > > backporting an otherwise simple and critical fix to slightly older > > > > versions rather complicated. > > > > > > Kinda. It's not that complicated to deal with that case, by wrapping > > > the actual data processing in an `if (len) { ... }` > > > > That's needed for sure, but do we risk looping forever on a particular > > batch of FIN segments without data with a given series of sequence > > numbers? > > > > Right now the loop terminates because the sequence moves forward. I'm > > not sure what happens without data while moving 'keep' around. Maybe it > > takes a few minutes to figure out (I haven't tried) but I wouldn't call > > that trivial. > > That should be fine, because we need to advance the sequence by one > for the FIN anyway, so we will move forwards. I might have forgotten > that in my quick example, which is a bug, but an easy one to fix. But we don't, in that loop, and there's a specific reason for it. FIN segments are a special case in that, if you receive more than one, you don't advance the sequence by more than one, even if the segments themselves are in the expected sequence. If you want to move the sequence increase into that loop (which might make sense with some extra care), perhaps it's worth doing that together with the whole https://bugs.passt.top/show_bug.cgi?id=125 at this point. -- Stefano