From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id EB9F45A0274 for ; Mon, 12 Feb 2024 00:17:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707693446; 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=13pCLK7dYTtWMKmKOJ4GhCBvN3K9gkZ/Cdmhaw/DR18=; b=DuNYyAvN7TH+dthyUoxCoCNPIzxVHG9w+iU5cPpYRg8dkIOyJv1PpU/V07RZl4gRZ81CbR wbccErivDJnkXohBeP/KOIF3rW8xDYR/+kYoGJ/t4l2cOPhw9sZBbUzIW+Fsz7xbeCpM/O +/l3sxvP8GuXGvyXtHRPfQ/xGh2bSlw= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-551-v0bxG2RyMta8H2_ponLrfw-1; Sun, 11 Feb 2024 18:17:24 -0500 X-MC-Unique: v0bxG2RyMta8H2_ponLrfw-1 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-56001b47349so1766599a12.1 for ; Sun, 11 Feb 2024 15:17:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707693442; x=1708298242; 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=13pCLK7dYTtWMKmKOJ4GhCBvN3K9gkZ/Cdmhaw/DR18=; b=BuElvXV3/rVw+XUASsh7V4Sx3NyC0qkHa1ND2RFCvKadTlwbE3RfhEWa5HYyhkbEbI zISRIY2QAOx/AOEglC4i48apcOBw6EEHQRyqGzxy9tXBZeo//l+QpKZijjc2Z3AdY7v2 CXus/l1VpGIFC0uAZ4z+qx7nru6GFD0+k9Fun0PYmt1AnSZiqjOhgahj8S8EHOK+lWlA u7tXc3y+MMf5IvXh7+F+L/syK0MRyxuIx2l/7Bc1bCxmhwipWqJjHVDlx8ibbpGayufT EtTrTztlPMFqVmYN0WUrxWAHzIM2446idk1v4dHvwGSEKqZA6aHYctne3R1ODQ2lDvql PjMA== X-Gm-Message-State: AOJu0Ywg6b3yEP6+HYbjzkTnKq+eU9AK/NyoK8mR8tAUvuvkcdX066Yz zn4Hhdd6QeXq5VThZ3zVjBCj0u+8t7wwV4jk/520PT5K/IETSttAhlbKwjoK/r8Mp5RZg4c8DC+ 81yzv/k3sir5sgpRPgVWmuBiha4dASc/k7w7yXzbR3/QrXSDs2v86+plgyUl4 X-Received: by 2002:a17:906:24ce:b0:a38:98ee:698c with SMTP id f14-20020a17090624ce00b00a3898ee698cmr3461223ejb.63.1707693442064; Sun, 11 Feb 2024 15:17:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IFu237uCGKw/kkGikm46edPV1jC1du0L7tj4JNJWZG/MPTp6+wST7YMjqXywVlXVcYlILQzzg== X-Received: by 2002:a17:906:24ce:b0:a38:98ee:698c with SMTP id f14-20020a17090624ce00b00a3898ee698cmr3461218ejb.63.1707693441774; Sun, 11 Feb 2024 15:17:21 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUiARONgcIj2bgVntYatj7QCjPTEliUbqmNdPGXUoQ4JxsmzZKRGGKjb3v2vXXAz3chWCLwiPgRujQ9PDQ+T/wIgA== Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id vh6-20020a170907d38600b00a3c838b0f1esm900965ejc.31.2024.02.11.15.17.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Feb 2024 15:17:21 -0800 (PST) Date: Mon, 12 Feb 2024 00:16:47 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] tcp: Fix subtle bug in fast re-transmit path Message-ID: <20240212001647.19ca7e2e@elisabeth> In-Reply-To: <20240207125721.1593836-1-david@gibson.dropbear.id.au> References: <20240207125721.1593836-1-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.1.1 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: JXSJXXYNXVXJFPKGPVQDBANGKM4BN2X3 X-Message-ID-Hash: JXSJXXYNXVXJFPKGPVQDBANGKM4BN2X3 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, jmaloy@redhat.com 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, 7 Feb 2024 23:57:21 +1100 David Gibson wrote: > When a duplicate ack from the tap side triggers a fast re-transmit, we set > both conn->seq_ack_from_tap and conn->seq_to_tap to the sequence number of > the duplicate ack. Setting seq_to_tap is correct: this is what triggers > the retransmit from this point onwards. Setting seq_ack_from_tap is > not correct, though. > > In most cases setting seq_ack_from_tap will be redundant but harmless: > it will have already been updated to the same value by > tcp_update_seqack_from_tap() a few lines above. However that call can > be skipped if tcp_sock_consume() fails, which is rare but possible. In > that case this update will cause problems. > > We use seq_ack_from_tap to track two logically distinct things: how much of > the stream has been acked by the guest, and how much of the stream from the > socket has been read and discarded (as opposed to MSG_PEEKed). We attempt > to keep those values the same, because we discard data exactly when it is > acked by the guest. However tcp_sock_consume() failing means we weren't > able to disard the acked data. To handle that case, we skip the usual > update of seq_ack_from_tap, effectively ignoring the ack assuming we'll get > one which supersedes it soon enough. Setting seq_ack_from_tap in the > fast retransmit path, however, means we now really will have the > read/discard point in the stream out of sync with seq_ack_from_tap. > > Signed-off-by: David Gibson Applied. -- Stefano