On Tue, Jan 13, 2026 at 01:12:09AM +0100, Stefano Brivio wrote:
> On Mon, 12 Jan 2026 15:26:14 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Sat, Jan 10, 2026 at 07:12:19PM +0100, Stefano Brivio wrote:
> > > On Mon, 5 Jan 2026 16:53:49 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >   
> > > > On Mon, Jan 5, 2026 at 12:18 PM David Gibson
> > > > <david@gibson.dropbear.id.au> wrote:  
> > > > >
> > > > > On Mon, Dec 29, 2025 at 05:55:58PM +0800, Yumei Huang wrote:    
> > > > >
> > > > > > +             if (c->pasta_conf_ns)
> > > > > > +                     die("--no-tap is incompatible with --config-net");    
> > > > >
> > > > > I don't think this is right.  We still can and should bring up 'lo' in
> > > > > the --no-tap case.    
> > > > 
> > > > I see your point, but seems c->pasta_conf_ns is only used for tap as
> > > > https://passt.top/passt/tree/pasta.c#n328, 'lo' is configured before
> > > > that line.  
> > > 
> > > Right, and the reason is that there are basic bits of functionality
> > > (probing pipe sizes if I recall correctly, or anyway probing for some
> > > kind of capability) that need the loopback interface to be up.  
> > 
> > Ah, right.  Drat.  In general I don't like us touching the guest
> > netlink at all if we don't have --config-net.  Hrm.. now what exactly
> > needs this.  It's not anything in sock_probe_features() - that runs in
> > the host ns.  Not pipe sizes, either - that also takes place in the
> > host ns (and netns is irrelevant to pipes, anyway).   There could well
> > be something, but I'm not sure what it is.
> 
> Actually, I tried, and I don't get any trouble (but I think I had some
> error when I added that in 2021).

Ok.

> But we implicitly break any outbound forwarding because our listening
> sockets will be unreachable (bind() succeeds though).

Networking doesn't work until you configure networking, that's the
normal state for !--config-net.  I don't see why that should be
different for outbound forwards than anything else.

> So... I would be
> wary of changing that at this point. There might be users relying on
> it, and it's otherwise harmless I guess.

I mean.. probably?  Almost certainly when pasta is creating the ns -
but in that case there's very little reason not to use --config-net
anyway.  The case I'm concerned about is attaching this to an existing
netns: this can alter the existing network config there.

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