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=JnRSIPWz; 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 72B215A004E for ; Tue, 13 Jan 2026 23:13:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768342401; 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=0jcsih0EBgbAgy2XQy+IPLuymKDwIwqYMHgQMdxFd3E=; b=JnRSIPWzTa1jp8saQHelHPYfm9R8tH3Ny7t2NwrF/GlY0/d9T6KODJle3BGmJ6Gk84nM1I YkkyAUHPovKBABGuHUPbpZg0EXkJzs4gG8+L1FXlfaTM+JcxS6f+JYLBILaaZ1ZrOtYvJV 3fiL/3GtpRBJuW6hyHQ7vuipFvoSE2M= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-231-iCl_wRgdOrKhEphnPKZzeQ-1; Tue, 13 Jan 2026 17:13:19 -0500 X-MC-Unique: iCl_wRgdOrKhEphnPKZzeQ-1 X-Mimecast-MFC-AGG-ID: iCl_wRgdOrKhEphnPKZzeQ_1768342399 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-47edfdc6c1aso5753605e9.3 for ; Tue, 13 Jan 2026 14:13:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768342398; x=1768947198; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=noNDfGANIwANRc5AN+ti+rbNfwoiXg4wJGMjaLQYUOk=; b=g3NKR3m+Ob95DALxC+apoM0RiiNRbdibjlBc+kw6uEZTHWaJ/1/uYUxC7EuUxj5smu 4kjJUybaIsoBWj1db9HqL7B1xpZgYkfXN+n5jg8lRdhlLcROkWza/w4jvZBCEuM02YIE lRhNG12WDwyub4iSOsgyaz0z2JqLJp9iyY/tifkchD3ZlhffcLPULPwJvfx51jYGXyZG nwyeUUcab4d+MX/Yp/5xfE9fj7uSujqgYb7jfFYweWmDXng8RUGVHJNhEv9YMrannMBj KueCiAIzL6kw39WRJYJbsTAvXavxaQyiIdowvKL93Gq9i4eQVBHeaP1fy/6DF6EbBTJo ahkg== X-Forwarded-Encrypted: i=1; AJvYcCV2GaEZTQpRx/FzMo+9ep7bs4VCLunXKtRbgGCKBwNr/FlgX/76F3uPsiva78aPqxRgE3VoMe7rMwQ=@passt.top X-Gm-Message-State: AOJu0Yw7wLyYgCXv3K6A33kThvuuePnQI5KHCAFatR71H2730JC4f3DT ouC3tF0oLA4qiqxA2yPjpaPWoSNjtyRiUag7kqrxhYrOp0djo9UhOdwEqik8y2Ua2yZxhqrJAEB okwfjRDLKBvFoCNCr9gG08pIFxOmYwGEotlRikciaUwsthP56UtCgVFoR1cjL5g== X-Gm-Gg: AY/fxX7uPfU+EJ+8qAhngVurvdnX3W1cDiy2O8pL924IC2Hkdw1hdrSK3c1XpiqO4Wa H9ia5zobAo5VFY0JA1S881DV9XNFZ1l6R78viExicXKiB+ApgCF5uCfY6JFMovGWWAUWD56qLXg +xLg7JV5T34gwOvtOEeYXYhQzMdzND0o5CnhWkwhpCllzFmlNVfSDwDJeMI83T2+05UzKKquybq Ok4bdeVHPgjmetXzF7lNBbhp8gxI2c/K9EUJUqJHvetFQfEw26C6Wgi4rjSIBnH31oDIVcPC594 aNcHFLXHsAyzIcL04iBcPvxLO8dB6F5cJpXwxuEgKo675qdpjkiV+3jWqjM3tBoOMpviRqvpsHm XMAAzBd9GhKVJpBgk9WhieLm57F854BtJfUt2oA== X-Received: by 2002:a05:600c:8217:b0:47d:403e:4eaf with SMTP id 5b1f17b1804b1-47ee3311593mr7490195e9.10.1768342397738; Tue, 13 Jan 2026 14:13:17 -0800 (PST) X-Received: by 2002:a05:600c:8217:b0:47d:403e:4eaf with SMTP id 5b1f17b1804b1-47ee3311593mr7490015e9.10.1768342397325; Tue, 13 Jan 2026 14:13:17 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5e3sm46232531f8f.35.2026.01.13.14.13.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 14:13:16 -0800 (PST) Date: Tue, 13 Jan 2026 23:13:15 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] conf, pasta: Add --no-tap option Message-ID: <20260113231315.2c5a7ad6@elisabeth> In-Reply-To: References: <20251229095558.918055-1-yuhuang@redhat.com> <20260110191219.29498050@elisabeth> <20260113011209.3c5ed9f6@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sfXKYqycoFXwMKp5TMr2a87HALYQghq1upugovTdejQ_1768342399 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: NRBPGU6U24UBNZJPTY4G4GKE4J33R3RY X-Message-ID-Hash: NRBPGU6U24UBNZJPTY4G4GKE4J33R3RY 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: Yumei Huang , 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 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: > > =20 > > > On Sat, Jan 10, 2026 at 07:12:19PM +0100, Stefano Brivio wrote: =20 > > > > On Mon, 5 Jan 2026 16:53:49 +0800 > > > > Yumei Huang wrote: > > > > =20 > > > > > On Mon, Jan 5, 2026 at 12:18=E2=80=AFPM David Gibson > > > > > wrote: =20 > > > > > > > > > > > > On Mon, Dec 29, 2025 at 05:55:58PM +0800, Yumei Huang wrote: = =20 > > > > > > =20 > > > > > > > + if (c->pasta_conf_ns) > > > > > > > + die("--no-tap is incompatible with --co= nfig-net"); =20 > > > > > > > > > > > > I don't think this is right. We still can and should bring up = 'lo' in > > > > > > the --no-tap case. =20 > > > > >=20 > > > > > 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 bef= ore > > > > > that line. =20 > > > >=20 > > > > Right, and the reason is that there are basic bits of functionality > > > > (probing pipe sizes if I recall correctly, or anyway probing for so= me > > > > kind of capability) that need the loopback interface to be up. = =20 > > >=20 > > > 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 i= n > > > the host ns. Not pipe sizes, either - that also takes place in the > > > host ns (and netns is irrelevant to pipes, anyway). There could wel= l > > > be something, but I'm not sure what it is. =20 > >=20 > > Actually, I tried, and I don't get any trouble (but I think I had some > > error when I added that in 2021). =20 >=20 > Ok. >=20 > > But we implicitly break any outbound forwarding because our listening > > sockets will be unreachable (bind() succeeds though). =20 >=20 > 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. =20 >=20 > 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. --=20 Stefano