From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine 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=eeAjX88E; 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 231115A0262 for ; Mon, 30 Mar 2026 10:45:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774860333; 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=F36g4F3WVgNXUl5XEg1+bmCJdknNUx/l0781VZBBXH8=; b=eeAjX88ENq+3aAV4QSujiXOdspSOnL2RZUvmnoKB6C0XpLnDCkXqFly+Rr96rzasjpy9tQ yzRrWSf0vjnWwB3go+ogxwu1gVTzJ97jG+fGfHTrAs4HNqx/kyD3BgHMNHZn0HUtBTN4BN cKMX6Bj/dZ9aTN8i9Hq1cmJFIKHnEGw= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-301-KV6PmUv0N1GPojER-pGFhQ-1; Mon, 30 Mar 2026 04:45:32 -0400 X-MC-Unique: KV6PmUv0N1GPojER-pGFhQ-1 X-Mimecast-MFC-AGG-ID: KV6PmUv0N1GPojER-pGFhQ_1774860331 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-48378df3469so29283865e9.1 for ; Mon, 30 Mar 2026 01:45:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774860330; x=1775465130; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=F36g4F3WVgNXUl5XEg1+bmCJdknNUx/l0781VZBBXH8=; b=ljZa0O2+7g6yDtLvUoKr7e3meussvfZvLNOQeC4ssFA98e0r26AkTXKJ0YtZWnEo9j eM11TMIB2HRKnQz5kpQzDuyZY+3L06mJri5bAp/H+CFyzlOGDQXROvzzVRumrCM0V+RJ UAMNa0yBc558bbw0/wJLTQC3x+X9PRI4sJzsaVniIV8yOf8UlKCfgBsIg8hDEAwIyipp stu4vThtrHVv9j9JFojdrvWWfYAQii1IuqZ8SXIaUjDvbGXSvpiBIHGkq3asj4OApLI1 pXrOi14MuXGZRfjwScHIyoS+A+M3l7ULJ9vekROax6TgPmmVoVn50yzJu6dstKApiwNa YJKw== X-Gm-Message-State: AOJu0Ywr464vML3zZtwaavZ2HDbh8yHHc+hhPlkEbXAwhup3RISuIY9C bNRybKoOlwikJ/IPSIRV5FwFEsY+5bWK0pRmHblPXZE0/WPx7MrktC+ZdGzO3PalkW4IPxm3pf3 xB9TD9j+osGb1H7hWH8J3pFZ2c+mKVBSJTxYbD5V/IcFZvI1CXgk7zw== X-Gm-Gg: ATEYQzxG8C91Ktkz+2cmDXCAFTNjd3hd6GVLiaxlYMyOuEfnzT+RteEDLj8ijcurCkg MMsHW9Sn3uD+413PtFdvlWbGU9LBBmwhbD0P77azsgVM1Od0/s4D6zRr1FWevl2Zwl4AQ84AOBY 7xrROHxhlhmqEYHbosWVGtczj5t87cfOBjXkaz/oN52tFxJl8caJggwIpqWq6QUeVBuHYIwn565 mxWtR0W5+ZTag4KqlRcIFL63qBlfYZ9pwWRYjbes+OWdUV7Q/VkipvZ1QH+RUYdFfpC3PwqeO1e XaZ7op+Twpd+k1D3wrB/Sxfk86DOGYlDd5LnzG9cnWlzaa+zTP65MDfIkzTR1oVf2EqXAeg8AA2 Wb7En20kn385SKDF2RW1InSJi6lnXOvr7SNSevhuSzsRBkMZy2w== X-Received: by 2002:a05:600c:8289:b0:47e:e59c:67c5 with SMTP id 5b1f17b1804b1-487290de830mr175273885e9.8.1774860329682; Mon, 30 Mar 2026 01:45:29 -0700 (PDT) X-Received: by 2002:a05:600c:8289:b0:47e:e59c:67c5 with SMTP id 5b1f17b1804b1-487290de830mr175273425e9.8.1774860328985; Mon, 30 Mar 2026 01:45:28 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4873062ec9bsm164012875e9.7.2026.03.30.01.45.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 01:45:28 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes Message-ID: <20260330104526.51f590c1@elisabeth> In-Reply-To: References: <20260327043430.1785787-1-david@gibson.dropbear.id.au> <20260327043430.1785787-16-david@gibson.dropbear.id.au> <20260329140226.18e910fb@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 30 Mar 2026 10:45:27 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: uo3IjEMv5gwSOhprVPw5dxGXwGUtI8Gjf-DYIhNSs98_1774860331 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 7V2T3I3RD2EOJKCBS5IAXQV3NTNFV4ZL X-Message-ID-Hash: 7V2T3I3RD2EOJKCBS5IAXQV3NTNFV4ZL 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 Mon, 30 Mar 2026 12:08:58 +1100 David Gibson wrote: > On Sun, Mar 29, 2026 at 02:02:27PM +0200, Stefano Brivio wrote: > > On Fri, 27 Mar 2026 15:34:27 +1100 > > David Gibson wrote: > > > > > All current pif names are quite short, and we expect them to remain short > > > when/if we allow arbitrary pifs. However, because of the structure of > > > the current code we don't enforce any limit on the length. > > > > > > This will become more important with dynamic configuration updates, so > > > start enforcing a length limit. Specifically we allow pif names to be up > > > to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrary - > > > there's no particular reason we have to use the same length limit as > > > kernel netif names. However, when we do allow arbitrary pifs, we expect > > > that we might support a similar number to the number of kernel interfaces. > > > It might make sense to use names matching kernel interface names in that > > > future. So, re-use IFNAMSIZ to avoid surprise. > > > > And what if... we used 128 instead, which is reasonably longer than > > UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1: > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html > > is still commonly used a path length limit, also by passt itself)? > > Well, certainly we could make pif names longer... > > > At that point we could embed UNIX domain socket paths as PIF name > > (possibly with some additional specifier) which _might_ be useful to > > forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=200 > > sense. > > ...but I don't think that rationale is compelling. The unix socket > path would be the equivalent of IP+port, not the pif. Right, that was the "obvious" idea we assumed so far, but I was thinking that if you want to stick to only PIFs and addresses in rules and flow tables (from what I understood, you would see some value in keeping that), we could think of modelling that UNIX domain socket as a PIF that can only map to a given TCP or UDP port (depending on the UNIX domain socket type) instead. It's a bit of a stretch but maybe it's convenient? On the other hand it would conflict with the current (and perhaps only reasonable) concept of PIF, that is, "the host", "the guest", etc. > I don't see how embedding a unix path in the pif would be useful. ...and maybe something else entirely: should we, one day, add support for multiple virtual machines, with each one connecting to different UNIX domain sockets (either data or vhost-user control sockets), would it be convenient to differentiate between those "TAP" (current name) PIFs using their UNIX domain socket path instead? Or would there be a separate table mapping PIF names to socket paths? This looks more elegant and flexible but I'm not sure if it's preferable to the former. > > It's not the only way to implement it, but perhaps it's one possibility > > that might make sense for what we know now? What do you think? > > > > It also has the advantage of being sufficiently longer than IFNAMSIZ, > > so that should we ever need to have stuff like "container_A:eth0" in a > > PIF name, we could have it as well. > > That's a more convincing case. Ok, I'll expand the pif name size for > the next spin. By the way, I forgot to mention, Podman container IDs (the ID you get from 'podman create', and if I recall correctly also from Docker) are 64 hex digits, which might be convenient to represent as 64 (printable) characters (instead of 32 bytes) for users to refer to. The OCI specification (surprise) just says that it's a "string", without defining the maximum length: https://github.com/opencontainers/runtime-spec/blob/main/runtime.md#state ...anyway, if Podman, Docker, or their users want to refer to containers using those IDs, that plus IFNAMSIZ would be 80 bytes. -- Stefano