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=OaYjFxtY; 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 506275A004E for ; Mon, 03 Feb 2025 10:45:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738575905; 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=pz3b8diUkL6DE6Eu6X/HopsNh8qiyrx6gGmfJQD+JwM=; b=OaYjFxtY1Nk5/PmtuKMLVbs6ipYgvQcq4ODu29kWpIRdvTnSUPW6usQsZ7AQenL4SOPPeE YhcYw0MNzzzCfHoSTXcz41pKQZjIvPczN/jS9Tk+V0SWcUGGkgacvVd31z6TNUfwSIh8tq dOVpGfigd/s8FcT+7TRrQpUoToxdNCw= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-452-X5cRy4zMPLq_d3mVHCb2oQ-1; Mon, 03 Feb 2025 04:45:03 -0500 X-MC-Unique: X5cRy4zMPLq_d3mVHCb2oQ-1 X-Mimecast-MFC-AGG-ID: X5cRy4zMPLq_d3mVHCb2oQ Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-38c4a819c0aso2525423f8f.3 for ; Mon, 03 Feb 2025 01:45:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738575902; x=1739180702; 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=pz3b8diUkL6DE6Eu6X/HopsNh8qiyrx6gGmfJQD+JwM=; b=suRuMwU8ArL1YbwHtuMYaC1qcFAyfl6b4IagChFc83mpP0R0aylyj3Ff0RgkG/muK3 2I8VmiaVCOWp5xKy5ifdYBrwNuFHg2ko5TYL9bNcrZcrk8nXDBoMJ+PuojsKZGNGK5pt yL4BeLlz4JTZ8ctOKU4s/8kDfPSYA71SYTWqYyS4P+ahBQZdU60Lj1hNys8S+4P2aFBm WtC8eTb8BGOB0KelarroINPWjtfhOxmbLSWE2/BV7HKWHarPGqFyMdf6kigLIwCWrG+m lR75kmev9xVk4ZYSDVAsXUnbNm65FoOTFiqq8Q3Ec2DvmfxiYooWrgrvGf4ypb7Hyth2 7ofA== X-Gm-Message-State: AOJu0YyO+joWtqf8FUoEZyuqPLAAym2U4BLazQd9mZKZDgy/B+dNtkQI N0NqJuCLnFUgf9/K2cP1PqET+kUbRNHveO0m4fdX6m8/bNpua6PK7bBvt3Koo2F5OyHYL1t505J eUtz7Z+IkDGtLacFE8t7Gb5KhcFZJDS9m5/K9eZmPO/rv+ZYHcg== X-Gm-Gg: ASbGnctQZKfsJLLZgAnvP0HssRiQJz3k5lScDUzRvvD7AiX8UI5tqZW9YDoT2xzBJFs a46mXrX8ixHCdrnRtZc88mbY9Mg24grmbgRHhs8XNuRXYm6YzYpeckv1s8EPdhH8qw8aWHF9Sci UVodPvB0nhcy82lamxf822SnfvYdV2J6I8erqaz1JOJboTp4IYXnPOvDpA1jznYcbJ+6iTP8tEw KTQ7qN0IKDI1hdseRdUngLOawrkNIShqEp5FSp1udpl0n/Wk6c9eUnhomSgtVX5BJUlpRIsi8c0 NonEAxT24s4KwosO X-Received: by 2002:a5d:64a3:0:b0:385:ddd2:6ab7 with SMTP id ffacd0b85a97d-38c520af7f9mr16542252f8f.52.1738575902038; Mon, 03 Feb 2025 01:45:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IG4XO9MlNVI1ZtysOQup3wNQljdZxNOQ7+z+yxyZbdVcuO2JHBjwMeMZpjBKkhD+DxcSds81g== X-Received: by 2002:a5d:64a3:0:b0:385:ddd2:6ab7 with SMTP id ffacd0b85a97d-38c520af7f9mr16542221f8f.52.1738575901641; Mon, 03 Feb 2025 01:45:01 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438e23d42c7sm151923755e9.3.2025.02.03.01.45.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 01:45:00 -0800 (PST) Date: Mon, 3 Feb 2025 10:44:50 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 17/20] vhost_user: Make source quit after reporting migration state Message-ID: <20250203104450.137b87d4@elisabeth> In-Reply-To: References: <20250131193953.3034031-1-sbrivio@redhat.com> <20250131193953.3034031-18-sbrivio@redhat.com> <20250203070932.2159fdc0@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: rz20DHKmHWkhm2tTLtAf_tx-rQQ11uecgXY4HvF8HP8_1738575902 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: HIX2Q3PMXTISECRQ572AUF6PBG5HSEZM X-Message-ID-Hash: HIX2Q3PMXTISECRQ572AUF6PBG5HSEZM 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, Laurent Vivier 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 Mon, 3 Feb 2025 19:52:37 +1100 David Gibson wrote: > On Mon, Feb 03, 2025 at 07:09:32AM +0100, Stefano Brivio wrote: > > On Mon, 3 Feb 2025 12:55:47 +1100 > > David Gibson wrote: > > > > > On Fri, Jan 31, 2025 at 08:39:50PM +0100, Stefano Brivio wrote: > > > > On migration, the source process asks passt-helper to set TCP sockets > > > > in repair mode, dumps the information we need to migrate connections, > > > > and closes them. > > > > > > > > At this point, we can't pass them back to passt-helper using > > > > SCM_RIGHTS, because they are closed, from that perspective, and > > > > sendmsg() will give us EBADF. But if we don't clear repair mode, the > > > > port they are bound to will not be available for binding in the > > > > target. > > > > > > > > Terminate once we're done with the migration and we reported the > > > > state. This is equivalent to clearing repair mode on the sockets we > > > > just closed. > > > > > > As noted on the passt-repair patch, I think this is based on a > > > misinterpreation of the situation. I think the problem is that the > > > sockets aren't closed in passt-repair, so the additional handle copy > > > is keeping the underlying socket open. This appears to work, because > > > it is causing passt-repair to also terminate. > > > > Right, exactly that. > > > > > That said, we probably want to terminate on the source side after a > > > succesful migrate anyway. At the very least we need to close() all > > > our sockets, and delete the corresponding flows, because we don't own > > > them any more. Quitting is probably the simplest way to do that. > > > > I'm not sure if there's an established behaviour for helpers supporting > > state migration. > > By "helper" do you mean passt as a device helper to qemu, or > passt-repair as a helper to passt. For the latter I wouldn't expect > so - it's only a weirdness of our situation that we need passt-repair > at all. If the former, I'm not really sure what you're after. I meant passt and similar. Is there any convention we should adopt? > > We could probably close sockets, delete flows, and keep things up and > > running for the rest (restart from a clean situation), but at that > > point we already the guest networking is already broken in a number of > > ways. So, yeah, maybe let's keep this instead. > > So, I realised it's a bit more complicated than that. We need to > identify exactly where the "point of no return" is. I'll discuss in > our call tonight. I think it's simply where we close sockets, by the way. -- Stefano