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=Beotwapn; 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 982A95A0274 for ; Mon, 03 Feb 2025 07:09:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738562978; 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=IhUUfkIovF6janHHTiQ+VflgjjgpwI9Ls1/ESibnef0=; b=BeotwapntpY+8ElSYLV5KDGcTYVIsakS5nozAfdNEm9ZabfdjlQABe+UkGsKd9HAZWJ36W NpYJ+hb0/mMWsgZwYQI2LIqwtXCi846a10+Svu/V55gIHZrxkVXM2PS2FMH2+ysyN6QNPh Vd8mVMFot9mC3ieMeQykT/wzf3A4J5o= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-507-oM7yhtzgMn-RQ7zl3xCQow-1; Mon, 03 Feb 2025 01:09:36 -0500 X-MC-Unique: oM7yhtzgMn-RQ7zl3xCQow-1 X-Mimecast-MFC-AGG-ID: oM7yhtzgMn-RQ7zl3xCQow Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-38639b4f19cso2190213f8f.0 for ; Sun, 02 Feb 2025 22:09:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738562976; x=1739167776; 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=IhUUfkIovF6janHHTiQ+VflgjjgpwI9Ls1/ESibnef0=; b=vRdsfNbNFs2tX2RiNlZxQUSOtW+4O/EA4qcB7+wtN1fdgwSSLrMyQp+AjPiyWRjQnQ pRo3T91A99sbHKolHMGWPKIlbh8T64V+9bLVd0biznNYpdzTbDTOPMSKLzdDY/QSi8pY usexM8GwehZgwdT+cHPaHpuso8UfGGa1rqMkrFpJ6JA0FVg0izB5y4fClULdQKffqS+H 3vJjcEr7bt4GK6IhRwYF42VuGbcQcQwvbX+P/yLevq0pc/l00BG9+3sGC7YYrG+XT2j0 +xMszeHrS2/Gko/tGZQMIeKJbh0CiGCCsarJUHvoBBC9vZat9bo+zsJKMv+lRWtqIW52 MwrQ== X-Gm-Message-State: AOJu0YyPYijJ5Ff1m93Opt0Uv6F5HX/ZAHZ4Dtp7J8aEerzpHESoxml4 rYiRRGQyDrOvnsFvoFmg/OhAQG7CwNzvvP5cnuftoitmXDmJdd+g+Eo8AAG2K2j8k5Rw3zf7nAM o/Ku/qcrwS0vXaD5+7Tt02Zik4iwkRqQ8KsAuQiT/b6/uEjw8ew== X-Gm-Gg: ASbGncv82qn9tgpnQItTw6P49ELlmcEcS0Z67/w/v+9YKX/x4MpIprV799jOvppGMwE fyOasvS4M7BtL4rp3Q6WXvp1DfD9JNdec9pMqVkbatMGTLmlAN4d5RH3paEoq9TDAbKPyvoel2A VqHNVhTm5gzx17Hs91lntV4haeIdwgVkvQkeqteJ+NYmZ8xgIyAey0o48ZSGcBnYvtvCb1J5tiM P0wFuSL9LxYuX3yByoTUCobO4dKZhFgNge0YSGxgvx/qQlp1vUrL1X8AQrbfWBF2mjn/AnF5Zmt bQR3p4RtZAfvdiNL X-Received: by 2002:a05:6000:1faa:b0:385:fb8d:865b with SMTP id ffacd0b85a97d-38c520a344emr20758479f8f.48.1738562975744; Sun, 02 Feb 2025 22:09:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IHyFLWpEsYBbHNMuJFUL/yjaFnwzVWTjPT11gG88bXMRNVOqas4GaWU/eInTeI9TnM6wtwZuA== X-Received: by 2002:a05:6000:1faa:b0:385:fb8d:865b with SMTP id ffacd0b85a97d-38c520a344emr20758464f8f.48.1738562975403; Sun, 02 Feb 2025 22:09:35 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c0eccc3sm11960871f8f.18.2025.02.02.22.09.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Feb 2025 22:09:34 -0800 (PST) Date: Mon, 3 Feb 2025 07:09:32 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 17/20] vhost_user: Make source quit after reporting migration state Message-ID: <20250203070932.2159fdc0@elisabeth> In-Reply-To: References: <20250131193953.3034031-1-sbrivio@redhat.com> <20250131193953.3034031-18-sbrivio@redhat.com> 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: 20eGUH-MOCrZpW1ljJl4TodxT0GAJn3Aun_fWVaIrLc_1738562976 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: NMRQ377XOUD6IJ6SVNCQEF3NHULTPXHO X-Message-ID-Hash: NMRQ377XOUD6IJ6SVNCQEF3NHULTPXHO 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 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. 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. > 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? 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. -- Stefano