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=XI+lqkKg; 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 CEE8D5A0008 for ; Fri, 21 Feb 2025 07:14:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740118467; 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=wUOT6I9OJmYboKKaqWxSXrUdhw7B5uTcad0PXJgeh2Y=; b=XI+lqkKgxnyqU1u0SDmiYh7K4rjOmDZisGo89rp8fY2hpWHl3fM7YKhlUeoPPlyWb8ABM9 nIOD0lHZoOahjUM5zpIUp8XoD24o/DhA2Ueil9LjEd+nLRpfHF78nEJzCqDBgcnHWq5Nrf IeFN2ySHl0ulKjl2vhe67zT1kiHKP7M= 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-646-_SrfTWKXPFe3eD6DwrvtWA-1; Fri, 21 Feb 2025 00:59:17 -0500 X-MC-Unique: _SrfTWKXPFe3eD6DwrvtWA-1 X-Mimecast-MFC-AGG-ID: _SrfTWKXPFe3eD6DwrvtWA_1740117556 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-38f628ff78eso870482f8f.1 for ; Thu, 20 Feb 2025 21:59:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740117555; x=1740722355; 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=wUOT6I9OJmYboKKaqWxSXrUdhw7B5uTcad0PXJgeh2Y=; b=UKB4phmjpuQ1iDFpQ5MqNbTU3LpMeOZss94DUez+ZYVj0b8kmGUw3m/Aa5Xf0+Q/NM 0amDOlpqrxtUiFqJaVkZv8r5VyhycI8/A07YVC2Hk3Tqh3m7UeJckn/d7U35aznCW37r PS8yFg3atZgMWbFenP5/rNrhpzQrLdmGWOqpVqwI8KnlCWO2N2BAzXsWjCubZN7khU1u v5LnzfKoKRQUEnC2uh923fdj+4CvP8jCRd8JGnUPRrzScSJKpDzncyFDwY2//KY9Wh1h Aof12wHUGBVgpqrKEp4srSTI9BQr1tBrk7v4BSQxIUR0xpNyd9VRMyXtw9IVLBismer1 rNZA== X-Gm-Message-State: AOJu0Yzarmh3f5vE09KhU1gNj8o1jPIg2qBvqp0PcjNJl8gawbK3gmLe fPBJQYH4Bw5gJyJ34IIlxFfv2C0alSF3tvsgfzZE/8nkytr5/yjREilUy03F/6UEALsf/eRAL/m fB9VGQPn42xUVn38eGt/PScC8A7JGO9Wc/cuhB/tiZldZnLKBPBVe9wJl7Q== X-Gm-Gg: ASbGncsr93K23VMzoQKT1LGjYOH/Hxg+Hxv9ohvIlZmH6WbgkzY+X5swRsQdVUahZth se/WIrd7+BQ3HKAt8hriF+Zyvk8075yuMYjL/lfmvD/3OJnXKfm3jY9MAM9tTOshjRYCet/0iqX D1YxEEB/h3/WMjRSn4JIiVhAhz/wBTM+oahySdAoMl75C4cDPoLGbdOCKK4b5crOh5f6T4lrDSH l8clo6l6L5ItqJqYGOWMKhW9efrl8pkUZ1iGFt7QJgrvGeLPVdGSd/ktJY7ciaYX3HI33sIse77 H6GNVSo7X6uYVHwN9ro2qItnmh0= X-Received: by 2002:a05:6000:1ac7:b0:38d:ae1e:2f3c with SMTP id ffacd0b85a97d-38f6f51db2cmr1349775f8f.25.1740117555499; Thu, 20 Feb 2025 21:59:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IHbm2a28sPZRlJ3WIOkfGywjzYeBOyN4hchONM3dxbSUCQAhQ29A6QYlXYZlyA1LywAsHKG4g== X-Received: by 2002:a05:6000:1ac7:b0:38d:ae1e:2f3c with SMTP id ffacd0b85a97d-38f6f51db2cmr1349764f8f.25.1740117555095; Thu, 20 Feb 2025 21:59:15 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38f259f8115sm22756002f8f.92.2025.02.20.21.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2025 21:59:14 -0800 (PST) Date: Fri, 21 Feb 2025 06:59:12 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 2/2] migrate, flow: Don't attempt to migrate TCP flows without passt-repair Message-ID: <20250221065912.404a1e88@elisabeth> In-Reply-To: References: <20250220060318.1796504-1-david@gibson.dropbear.id.au> <20250220060318.1796504-3-david@gibson.dropbear.id.au> <20250220090726.43432475@elisabeth> <20250220113800.05be8f5f@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: vDYYHKTXPW240nWPGNyXsIzM9-h3yhg2KhhVBixcdKs_1740117556 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: F6X35HYTZP65TWWRKF4UYB3DODBEJVSQ X-Message-ID-Hash: F6X35HYTZP65TWWRKF4UYB3DODBEJVSQ 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 Fri, 21 Feb 2025 13:40:12 +1100 David Gibson wrote: > On Thu, Feb 20, 2025 at 11:38:00AM +0100, Stefano Brivio wrote: > > On Thu, 20 Feb 2025 21:18:06 +1100 > > David Gibson wrote: > > > > > This sort of thing is, incidentally, why I did way back suggest the > > > possibility of passt-repair reporting failures per-fd, rather than > > > just per-batch. > > > > Sorry, I somehow missed that proposal, and I can't find any trace of > > it. > > It may have just been on IRC somewhere. > > > But anyway, the problem is that if we fail to read a batch for any > > reason (invalid ancillary data... maybe always implying a kernel issue, > > but I'm not sure), you can't _reliably_ report per-fd failures. > > *Usually*, you can. Worth it? > > Ah, I see. We could handle that by being able to report both per-fd > and "whole batch" failure (equivalent to failure on every fd), but > that would complexify the protocol, of course. By the way, after having another look at the kernel interface and implementation: this makes no sense. Either we're able to set repair mode for all the sockets, or for none of them (EPERM). And if there's any invalid file descriptor in the set, we'll get EBADF for the whole sendmsg(). The stuff I'm proposing below is well beyond my threshold of things that make no sense to implement, but at least it limits damage in terms of complexity (and hence of potential impact on the actual usage, because that's what we're talking about here: a die() that makes no sense but now proves to be actually harmful). I wouldn't go any further than that. > > In any case, if it's simple, we can still do it, because passt and > > passt-repair are distributed together. You can't pass back the file > > descriptors via SCM_RIGHTS though, because we want to close() them > > before we reply. > > > > Another alternative could be that passt-repair reverts back the state > > of the file descriptors that were already switched, on failure. > > That might help a bit, we'd still need to rework the passt-side > interface to know what needs reverting at the right stage. Not for what I'm proposing: 1. passt sends 1 (TCP_REPAIR_ON) for sockets 2, 3 2. passt-repair sets repair mode for 2 3. passt-repair fails to set repair mode for 3 4. passt-repair clears repair mode for 2 5. passt-repair closes the connection to signal failure 6. passt knows that repair mode is *not* set for any socket in the batch The interface remains the same (per-batch error only), but you can rely on the whole batch to have failed. You already can, even with no changes in passt-repair (see above), by the way. -- Stefano