Re: [PATCH] conf, pasta: Add --no-tap option

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 13 Jan 2026 13:39:34 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

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

Yes, I understand your point, and even agree in general. I'm just
saying that that part worked until now without bringing the loopback
interface up, and we'd break it.

By the way, --config-net configures a lot of things, at least by
default, that might be done in a different way, even though it's not
the default simply because the functionality didn't exist at the
beginning, as I implemented passt with its DHCP server first.

Bringing up the loopback interface is much more universal than that.
I guess virtually all users would want to have it brought up. And
especially with --splice-only, *not* doing that would become quite a
nuisance I think. You would start pasta as:

  pasta --splice-only

and nothing would work, unless you do:

  pasta --splice-only --config-net

where "--config-net" now means... bring up the loopback interface.

It might be considered more correct, strictly speaking, but not really
intuitive. Just let users bring the loopback interface down I'd say,
if they really need that.

There's by the way a small asymmetry in all this: the kernel adds
all addresses one normally needs to the loopback interface as you
bring it up, without external intervention. It's not exactly
something we would "configure" separately.

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

Strictly speaking, yes, but I can't really picture anybody using
namespaces relying on the fact that the loopback interface is down.
I mean, given the choice between:

  Bug 190 - Port forwarding doesn't work with --splice-only

and:

  Bug 190 - pasta unexpectedly brings up loopback interface in container

...the first one, you could explain why and close it. But the second one
would never be reported. Well, I guess.

-- 
Stefano