From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=bCzFtNVU; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 8D8A55A0275 for ; Sat, 08 Feb 2025 01:06:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738973183; 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=AUDxhW4GX+1VbfueCZGlD+/+prTTCsAIxyJ9Fz/qaaM=; b=bCzFtNVUWH6xfzlNBNQRqOJaFah4oh/VaEkhd7/TJ3Pe3reR4uGlyf1SZzM/030T81uupz OWSlXfxbRwYkhMQsJb3qqgghIY1vyRiKDSUUL0yJgXU6ukEAu0yrEgGRJ+t2iYImMvBIDT CQyEWbum0KCaEi4I5JlBTaReadz0VIA= 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-694-jDar8_7LPYiEMDCxdnD8Qg-1; Fri, 07 Feb 2025 19:06:21 -0500 X-MC-Unique: jDar8_7LPYiEMDCxdnD8Qg-1 X-Mimecast-MFC-AGG-ID: jDar8_7LPYiEMDCxdnD8Qg Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-38dc6aad9f8so792335f8f.1 for ; Fri, 07 Feb 2025 16:06:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738973180; x=1739577980; 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=EprtaRJm3A1S9wMteZNbTQtj5xkzorLtvQGE53a0G4A=; b=wwQmACwXVg0j7XQLuLuwZnuTmjAIeUFkdZHm2SfkDUjKsSYHRwnVhujJlQdXaLyLw5 T6hsKzBH6WnsuLOMyIkMuDwokZ05uyfQW6N8XhHqhFXWkYbwp7Dwjqz8ngOnYGHWWF5g NdKGUgQm32m/ylncHQjOqqI+WVeqCt+98GfG8Ip9U2W1ypKqNOhCbYr8KzhY9GoM7d2F 0PTlT0JFkVaaILxIXJOKUX+YKLe13n3/YR3HfvxXORV1Ydd7uGSYGMEKGSVvy6xWsd7o f94fiiSw9sfPWxml5hUCsDTXLenOjHWct+bsy/f5/YoMTkdeDIu4n6MKcrFYT8swTeY9 I6Rg== X-Gm-Message-State: AOJu0YzLjZI+7CAXQJ+y1ikMLhzFig8r6Se9upat8Anh96YsqZfuZwQu q/ZDDrAx22Meqi5Vq6E8d4Z5RtgwXjY/lrZmw22e0BdYon+fgVFXDGyTsLTgRsEA8S7xBNvyiSr +sNKiYXO+wZFeYjQkWyzEdJMEgKsaiabCoOY5+uVdB+p3CZ+piy+Yy7hIkA== X-Gm-Gg: ASbGncvCC02E+mGNUMpIMnSOxaVc5fHlXPiOxKnURO5di/ks1NfForWGMr9M0ksjkM7 bCh417n/SsFWSl1uHXZXe2cx/XBtu+RCsZizDN0+NavtLUtKkZx/ozaWV05RFBq3uJeWLY4pV3+ S53n053O9k3NKh/k8i4qEj4CgrtetCSKmsa5aDnHdNkL+1ebPVeFbXwEtwuos8Q1WvNG+liLPWd s1k3686+LjCX3WKXoGMiXnKKHirz92ljx5kxG8MGgwoqVlxp/bOL6bP8WZPO1uMCuH+SCRLoJWV mbxkS1mUfGvwmQ+C X-Received: by 2002:a05:6000:1fac:b0:386:4244:15c7 with SMTP id ffacd0b85a97d-38dbb305242mr6751613f8f.25.1738973179638; Fri, 07 Feb 2025 16:06:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IEleU80zXgNMkKqyjzT8UkrXovyubGky1gmggZ6SWWN7jZjg0KU+j6Nynoa6kKbmKo/+h323Q== X-Received: by 2002:a05:6000:1fac:b0:386:4244:15c7 with SMTP id ffacd0b85a97d-38dbb305242mr6751602f8f.25.1738973178955; Fri, 07 Feb 2025 16:06:18 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4391da9648dsm72046105e9.7.2025.02.07.16.06.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 16:06:16 -0800 (PST) Date: Sat, 8 Feb 2025 01:06:14 +0100 From: Stefano Brivio To: David Gibson Subject: Re: migrate/bidirectional debugging Message-ID: <20250208010614.27c82ea9@elisabeth> In-Reply-To: References: <20250207075115.78b6e1da@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: vI2L-4Tk8UMZ1vnWugnIb4zvv3BnejlaxUt4HKEHwXg_1738973180 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: HKY3LMB4VZKLLGRU34KNLZAYCGI6YN3S X-Message-ID-Hash: HKY3LMB4VZKLLGRU34KNLZAYCGI6YN3S 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 Sat, 8 Feb 2025 10:44:03 +1100 David Gibson wrote: > On Fri, Feb 07, 2025 at 07:51:15AM +0100, Stefano Brivio wrote: > > On Fri, 7 Feb 2025 17:26:35 +1100 > > David Gibson wrote: > > =20 > > > It kind of seemed like we were sendmsg()ing "and from guest 2" and it > > > was bouncing straight back to our socket, instead of being delivered > > > to the outer pasta. =20 > >=20 > > Oops. > >=20 > > diff --git a/tcp.c b/tcp.c > > index 0f05011..b7f5169 100644 > > --- a/tcp.c > > +++ b/tcp.c > > @@ -2796,6 +2796,12 @@ static int tcp_flow_repair_queues(int s, > > =09=09debug("Read socket %i receive queue: %zi bytes", s, rc); > > =09} > > =20 > > +=09v =3D TCP_NO_QUEUE; > > +=09if (setsockopt(s, SOL_TCP, TCP_REPAIR_QUEUE, &v, sizeof(v))) { > > +=09=09err_perror("Setting TCP_NO_QUEUE on socket %i", s); > > +=09=09return -errno; > > +=09} > > + > > =09return 0; > > } > > =20 > >=20 > > otherwise, I guess, there's a time window in which we might be writing > > that message to our queue instead of writing it on the socket, even > > with repair mode off. The write might be pending or something. =20 >=20 > Huh. It somehow never occurred to me to think that repair stuff might > be happening after we turned repair mode off. Is that actually the > case, or could it be that the passt-repair protocol bug meant repair > mode sometimes wasn't turned off? Nah, sorry, never mind, it's all fixed by the patch for passt-repair I sent. Setting TCP_NO_QUEUE would hide the issue. > If repair mode stuff is happening after turning it off, I'd say that > is a kernel bug, although a much less nasty and more easily worked > around one than I'd feared (I was contemplating whether repair mode > connect() might be looking something us wrong and wiring things up to > the wrong place). >=20 > > With this, the stray packet is gone. I spotted this case now: > >=20 > > $ tshark -r test/test_logs/passt_2.pcap=20 > > 1 0.000000 88.198.0.164 =E2=86=92 169.254.1.1 TCP 71 58150 =E2= =86=92 10006 [PSH, ACK] Seq=3D1 Ack=3D1 Win=3D1024 Len=3D17 > > 2 0.000031 88.198.0.164 =E2=86=92 169.254.1.1 TCP 54 58150 =E2= =86=92 10006 [FIN, ACK] Seq=3D18 Ack=3D1 Win=3D1024 Len=3D0 > > 3 0.000059 169.254.1.1 =E2=86=92 88.198.0.164 TCP 54 10006 =E2= =86=92 58150 [RST, ACK] Seq=3D1 Ack=3D1 Win=3D256 Len=3D0 > > 4 0.026443 169.254.1.1 =E2=86=92 88.198.0.164 TCP 74 48150 =E2= =86=92 10001 [PSH, ACK] Seq=3D1 Ack=3D1 Win=3D256 Len=3D20 > > 5 0.026538 88.198.0.164 =E2=86=92 169.254.1.1 TCP 54 10001 =E2= =86=92 48150 [ACK] Seq=3D1 Ack=3D21 Win=3D1023 Len=3D0 > > 6 0.026557 169.254.1.1 =E2=86=92 88.198.0.164 TCP 54 48150 =E2= =86=92 10001 [FIN, ACK] Seq=3D21 Ack=3D1 Win=3D256 Len=3D0 > > 7 0.026656 88.198.0.164 =E2=86=92 169.254.1.1 TCP 54 10001 =E2= =86=92 48150 [FIN, ACK] Seq=3D1 Ack=3D22 Win=3D1024 Len=3D0 > > 8 0.026675 169.254.1.1 =E2=86=92 88.198.0.164 TCP 54 48150 =E2= =86=92 10001 [ACK] Seq=3D22 Ack=3D2 Win=3D256 Len=3D0 > > 9 318.959707 fe80::1 =E2=86=92 ff02::1 ICMPv6 158 Router = Advertisement from 9a:55:9a:55:9a:55 > >=20 > > That RST we send as frame #3 looks unwarranted. I wonder if we get > > packets from the target guest before we have a chance to set up flows. = =20 >=20 > I don't think that should be possible: the target guest shouldn't be > resumed until after we ack the check_device_state. Correct, I also figured that out later. --=20 Stefano