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

On Tue, 13 Jan 2026 13:39:34 +1100 David Gibson 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 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 wrote:

...

On Mon, Jan 5, 2026 at 12:18 PM David Gibson 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