From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 1CE815A028F for ; Tue, 23 May 2023 08:14:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684822455; 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=nYm/xbHvfYZVRbhS1GIKJJ1UrvWVQfBvVRfH0/r/uv0=; b=fcISU+6VaQF44zxZ2WbqVuBTRXi5WimJ3W2kk5dTVgXELZYMyJl73pNax30xqFJD2XPB7T dC1L4FIJ890btPCOkFt1Jf6rPB2l3Ea7s04v4s5C9EMy3uIPB5fyERVCWRSJJtHIFYBwjb af1X9VoAAVZFzP64DHYRv/p37M+4Lvs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-408-2CGF1fCnPASAFkJ4VDVYfg-1; Tue, 23 May 2023 02:14:12 -0400 X-MC-Unique: 2CGF1fCnPASAFkJ4VDVYfg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 25C22802355; Tue, 23 May 2023 06:14:12 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C5990482060; Tue, 23 May 2023 06:14:09 +0000 (UTC) Date: Tue, 23 May 2023 08:14:07 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v2 03/10] netlink: Add functionality to copy routes from outer namespace Message-ID: <20230523081345.4f0a0274@elisabeth> In-Reply-To: References: <20230521234224.2770015-1-sbrivio@redhat.com> <20230521234224.2770015-4-sbrivio@redhat.com> <20230522115851.2c7f7736@elisabeth> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: XFVT5DZP5SYGBOEKK3RFVFYCVD4GAGGJ X-Message-ID-Hash: XFVT5DZP5SYGBOEKK3RFVFYCVD4GAGGJ 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: passt-dev@passt.top, Callum Parsey , me@yawnt.com, lemmi@nerd2nerd.org, Andrea Arcangeli 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, 23 May 2023 13:08:21 +1000 David Gibson wrote: > On Mon, May 22, 2023 at 11:58:51AM +0200, Stefano Brivio wrote: > > On Mon, 22 May 2023 18:42:01 +1000 > > David Gibson wrote: > > > > > On Mon, May 22, 2023 at 01:42:17AM +0200, Stefano Brivio wrote: > > > > Instead of just fetching the default gateway and configuring a single > > > > equivalent route in the target namespace, on 'pasta --config-net', it > > > > might be desirable in some cases to copy the whole set of routes > > > > corresponding to a given output interface. > > > > > > > > For instance, in: > > > > https://github.com/containers/podman/issues/18539 > > > > IPv4 Default Route Does Not Propagate to Pasta Containers on Hetzner VPSes > > > > > > > > configuring the default gateway won't work without a gateway-less > > > > route (specifying the output interface only), because the default > > > > gateway is, somewhat dubiously, not on the same subnet as the > > > > container. > > > > > > > > This is a similar case to the one covered by commit 7656a6f88882 > > > > ("conf: Adjust netmask on mismatch between IPv4 address/netmask and > > > > gateway"), and I'm not exactly proud of that workaround. > > > > > > > > We also have: > > > > https://bugs.passt.top/show_bug.cgi?id=49 > > > > pasta does not work with tap-style interface > > > > > > > > for which, eventually, we should be able to configure a gateway-less > > > > route in the target namespace. > > > > > > > > Introduce different operation modes for nl_route(), including a new > > > > NL_DUP one, not exposed yet, which simply parrots back to the kernel > > > > the route dump for a given interface from the outer namespace, fixing > > > > up flags and interface indices on the way, and requesting to add the > > > > same routes in the target namespace, on the interface we manage. > > > > > > > > For n routes we want to duplicate, send n identical netlink requests > > > > including the full dump: routes might depend on each other and the > > > > kernel processes RTM_NEWROUTE messages sequentially, not atomically, > > > > and repeating the full dump naturally resolves dependencies without > > > > the need to actually calculate them. > > > > > > > > I'm not kidding, it actually works pretty well. > > > > > > If there's a way to detect whether the kernel rejected some of the > > > routes, it would be nice to cut that loop short as soon as all the > > > routes are inserted. Obviously that could be a followup improvement, > > > though. > > > > Yes, there's a way, but to keep things asynchronous in a simple way we > > process errors from nl_req() only at the next request. > > > > This part doesn't really need to be asynchronous, though: we could add > > a flag for nl_req() saying that we want to know about NLMSG_ERROR right > > away. This looks relatively straightforward, and already an improvement > > in the sense you mentioned. > > > > Actually parsing the error and finding out the offending route is a bit > > more complicated, though. > > Right, but we don't necessarily need to do that: all we need is that > if there are *no* errors we can stop the loop early. Yes yes, that's what I meant with the paragraph before. By the way, note that in general we'll get EEXIST in the "extended ACK" for any message we send, because we just inserted addresses that already created their prefix routes. We could think of setting the IFA_F_NOPREFIXROUTE flag on addresses, on NL_DUP in nl_addr(), or even always, to avoid this. -- Stefano