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=X44bZyC+; 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 81B8B5A062A for ; Fri, 21 Feb 2025 08:03:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740121388; 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=yreQxAY6+CaTdjRFFJ7cYFP0JRiKpiB1fAxOnwfKxTU=; b=X44bZyC+VceYPMOU1sF/D9nktM8Uj6K80mKw1iUYk/8oJPSiu0qlcyOB3U5fUuxIsJU+GC Q9TSM1ob0g7ffPxGIooBJanKZG3M/wkC8XE9SSKQdMPb0NtteoItEbZFHNQYOVgfh0LlBs JoublLABFibCfbdxoCEnBVHcCTgDnwk= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-124-VH4Wu1fZPauUHKJMB377Ow-1; Fri, 21 Feb 2025 02:03:04 -0500 X-MC-Unique: VH4Wu1fZPauUHKJMB377Ow-1 X-Mimecast-MFC-AGG-ID: VH4Wu1fZPauUHKJMB377Ow_1740121384 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-38f55ccb04bso1168073f8f.3 for ; Thu, 20 Feb 2025 23:03:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740121383; x=1740726183; 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=yreQxAY6+CaTdjRFFJ7cYFP0JRiKpiB1fAxOnwfKxTU=; b=pdaaG1FPwV0ciY2xxMGj1iUiZcwgQMxzIUeDN9zX6EvFWNPOfB+Om5DUp6ocmiTCEy 4k1obUdMmLsoMfbrR+N8Csp/PNcVLz9LwHgr8p70nw4q977LtLGq5X1u8DOXonSMgzLa UNso4O6pmvKw8K0WJEZHefn/cbVtQ3MSnQkriJfDI+nI4CtLMNy4pJOUzVpUuecFBnP7 FfsWDujQPgfJKBV7jcDq4/cZA6IxFQTuhiJcDkMNJ/SpxKEJNnnooH4lsxxNgOXP6SpJ rNZgqr7gSw4n49xQsFrhHYW3v8M06+hsnwVVECNLQMYfjxJz4RHLLGQxGq6IsqWuEc0W f7Fg== X-Gm-Message-State: AOJu0YwKFsy8VqTUOr2cdG2SrBawUWZwMkyDlv8yD91M6fwa1ELw3gSp nxWuge7fruXy7dpc+XSpRMuubL5ebWXyD1+dCgqvfHT7tySXclhmpjWYb5zhmUWbef9dE256DVp 3S77qkswFwp5oz6MCbRHOpD3cBPBZjERpX+jsbS51oukj0O3O5DUYUYMgLA== X-Gm-Gg: ASbGncvjk6LAJZdkf10eH2pOfxpx9TD2nV35kgTbjVhnJcEULGiVSC0BJT4a4uTzTKi BNDNmSKBYbpDTWnK0AyEjAnQS9aufo2FnPrlHU4Urbuj2jXKjv9ofT6J0HZJTOQX3Ron9bsXdV3 tohE00U4Nw6OAF+TEa9f7Cyw98DQ/VCsJqbD7JjSIgJ/u3A5ux1IMfBQOnL/QfBwU+v0VYfZBmX 9f+jQEFZbz7MXXwcV9/FwB9wSIZLoZ7/vCNggwX4F0tkn4L2+hMIF9/oBRDRVjo0BdRm9Uzwbol iBXx15WysaCjyodEwsiz4QC3K7I= X-Received: by 2002:a05:600c:154a:b0:439:44eb:2d81 with SMTP id 5b1f17b1804b1-439ae1f34f8mr14862645e9.15.1740121383392; Thu, 20 Feb 2025 23:03:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IHFxts5ZfjEKsk2hJfhC5oA8VlhpwJ9mDoE5LY3UXtPCRninWhSMQTqIKoFi9GQFnuthYoqDw== X-Received: by 2002:a05:600c:154a:b0:439:44eb:2d81 with SMTP id 5b1f17b1804b1-439ae1f34f8mr14862315e9.15.1740121382896; Thu, 20 Feb 2025 23:03:02 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-439b030c615sm8067715e9.32.2025.02.20.23.03.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2025 23:03:02 -0800 (PST) Date: Fri, 21 Feb 2025 08:03:00 +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: <20250221080300.3dcf97a2@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> <20250221065912.404a1e88@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: O4A4rUHTvySV2GDz9MUQyxZjSp2rlvZ5K3ZErY1JPWU_1740121384 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: QJGKI54CF5WVMSMDQVCMI5TJ2TBF5I3S X-Message-ID-Hash: QJGKI54CF5WVMSMDQVCMI5TJ2TBF5I3S 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 17:37:18 +1100 David Gibson wrote: > On Fri, Feb 21, 2025 at 06:59:12AM +0100, Stefano Brivio wrote: > > 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). > > Well.. probably. I suspect something sufficiently insane in an LSM > could break that rule. Not in the LSMs we ship policies for, because we don't run as root, so we can't magically relabel (setfilecon()) sockets or change subprofile (aa_change_hat()) before/after creating some, even if we wanted. And from the little I know of TOMOYO that should be impossible as well. > > 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 > > Again, it shouldn't happen in practice, but you will get a mess if you > ever managed to set repair mode, but failed to clear it. "It shouldn't happen in practice" == "It doesn't happen". And again, in this impossible case, we would either get a socket that's stuck, for two hours, or close it because we get some other error on it. > There's a similar question in the other direction, if passt is trying > to REPAIR_OFF, and we fail part way through. Should passt-repair > REPAIR_ON again? I'm not sure it has the information to make a sane > choice here. Yes, I think it should. The information it has is that it just set REPAIR_OFF, so repair mode was presumably on to begin with. > > 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. > > Well, I just finished implementing a simple way of reporting partial > failures. I guess see what you think of it. I guess it conflicts with my priority which is to fix actual bugs without introducing new ones, but other than that, I'm not necessarily against it. -- Stefano