Re: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

On Sun, Mar 29, 2026 at 02:02:27PM +0200, Stefano Brivio wrote:
> On Fri, 27 Mar 2026 15:34:27 +1100
> David Gibson <david@gibson.dropbear.id.au> 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.  I don't see how
embedding a unix path in the pif would be useful.

> 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.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]