From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202502 header.b=ancY5ygd; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 75FB05A0272 for ; Mon, 03 Feb 2025 10:25:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202502; t=1738574694; bh=KLCMlKHMXs3tbHzXQ8QRlYHIhiFgXIh+ddkmCFIR1B0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ancY5ygdWqA+9CFD9AIgi1VQNqskUxLZes/FWzgksUu9jacHdXQ/ofJLTs0lvj3Uz +QBLP39V+yu7mVoCg5vCgBcAiS9YJ2CF6TAH7oFbF+g82osAQuFwkbmx9iznP1j2RV vhPbUC3rOA5vJ+zUhSQpy0VVy9jzmJu5gHZ9k43KPaixBCf+5miqjR1QLnYgIcxaG6 n1ME2VY1Qjfx48Fo+GluKikvf27f4RnD3jWRNxOFudozYcCnByOW6R2858KX1I/L2j /1fOO//G3sFkwB2WPZh821TNsc7gSyQ+SqcFO5dZhwJx20H1q1XJjs+aD+x/jydUth DNiiQIwTqOtvg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Ymh0k34QFz4wxm; Mon, 3 Feb 2025 20:24:54 +1100 (AEDT) Date: Mon, 3 Feb 2025 19:52:37 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 17/20] vhost_user: Make source quit after reporting migration state Message-ID: References: <20250131193953.3034031-1-sbrivio@redhat.com> <20250131193953.3034031-18-sbrivio@redhat.com> <20250203070932.2159fdc0@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NOyHV5a84nnWg4Vi" Content-Disposition: inline In-Reply-To: <20250203070932.2159fdc0@elisabeth> Message-ID-Hash: TF4OY3W4XRPJV27FTGTSZ4PBQQCDZF4X X-Message-ID-Hash: TF4OY3W4XRPJV27FTGTSZ4PBQQCDZF4X X-MailFrom: dgibson@gandalf.ozlabs.org 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: --NOyHV5a84nnWg4Vi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > 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. > > >=20 > > > 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. > > >=20 > > > 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. =20 > >=20 > > 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. >=20 > Right, exactly that. >=20 > > 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. >=20 > 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. > 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. > > Which also makes me realise, on a *failed* outbound migration, we _do_ > > need to turn repair mode off on everything again. Is that implemented > > yet? >=20 > No, sorry, that's the "/* TODO: rollback */" comments in > flow_migrate_source_pre(), flow.c. But other than that, it should be > pretty much implemented, at a migrate.c level. Right, I realised that a bit after I wrote this. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --NOyHV5a84nnWg4Vi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmegg9QACgkQzQJF27ox 2Geotw/+K3Lu+2AH32s+bSfUXsDuUZA/uDX06HEM0vqOPbbq1rvDz+e3ocBcqfuK jao739tnR0ISzQjnporL9/FBpcH45et3HWkAzzeJ8UN8gIzQ1lzF2hM5YerBx1UV 9hZ2ESmUvoKRsajc8bB8gsb0Bk/KG6OTI1hZ54RPU5WW//9ATyIFhycCYPTLmRqO uLgOQx58sjq16kKgre4TLHDbA+Y1xdIJvCWpXuIguihJjA69xo9wWq/I3FiGTRvN HzdXVUEcFNHSeVBnrPKrhHaiX7Vizms9YOwZ5sDEhQzeSVFolqyu8D5nlGtyIH4w yTszUWBZ7wrIj5ghJuHZDr1fi1UkaUVsbKUGNkA2AzWCJIGVnht71iZmJ9yextDg vGavUxJjFe+9e9PUUrXSbYRXzyEyy41Vluj3+2G9E3/4kLzRdK/CmqyO+PJB+QUi TD1XDAiY9u8FOo7Cr/ZJN8FkJdm2okpPUdlKgnIYpSUVbX7q1EAtWcE0dAVttUtC FxawodsGltnJT06A1jSVbpZ4JT59G+whhk+DimZvq/JSpE+vo8J73rrV+vxYBK2m CwVUWNzypIxEG5D8pE+/U93ZWfYH1VRORXUIrLTS0pG+vndp0f4HO507T8qsb0t3 aBjduWpZxYBGHejU4yiQiofYZqzlKjGsGq+WF4UkQUHa//vu964= =O5I8 -----END PGP SIGNATURE----- --NOyHV5a84nnWg4Vi--