From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=quarantine dis=none) header.from=redhat.com 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 422615A0265 for ; Wed, 21 Oct 2026 01:57:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792540620; 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=meyv9Z2oortlVCVwrOWSvTdKua7E5TMX5+tesJZODuA=; b=YusyBpUZGdFYxyFsLTcvEjBipQON3eLuV3EIvkJHDsYj7qoYRXlM96JaZxraIIAtr5VzVP R/6boK5O9EnC32LWgCziNQTBt/IqA6NseHohXT0eqbCZsM8RxZflKvE+leWNfYK3Lufy6X wNx2T/k+05dch+E36hL6orRB1Az98hY= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-295-WYMnECU8Pu6Dq28zLLh7fA-1; Tue, 20 Oct 2026 23:56:58 +0000 X-MC-Unique: WYMnECU8Pu6Dq28zLLh7fA-1 X-Mimecast-MFC-AGG-ID: WYMnECU8Pu6Dq28zLLh7fA_1792540617 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-48e00f3929bso892333f8f.0 for ; Tue, 20 Oct 2026 16:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792540617; x=1793145417; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=meyv9Z2oortlVCVwrOWSvTdKua7E5TMX5+tesJZODuA=; b=mjGP4Dr14C+LO5lxXi97zOmZ7TjdbHDrak5Us3cT3YE7weJDWOJWVdRSYRWtSa1ZCj dONR0vMWgOZH8wJbZdBqw9i0PrdAmOxNmLeaB6j278VncSnTtFxRpSTt93uSg9ysKkUx +2YERN2ds0Sx1BL44uATp0srX6/wsYFtX8WWRE66QPST3FEbnXkGN3iK2XfQng9DBHVC 6csRfUnukbN438J25UkRxsOTfUQw51CsoQgxlbZiHTlXTrpB3dAk6gn9BEUnRaRhraKR mnA03V92CTqLz6frtziLDbr4oLxahroFOc/ndM8lW1UNA5kZDL43s+cL6rEVaXUxL9xp 5wVg== X-Gm-Message-State: AFq9FYI2uArYTABb9QATGYNlFpzmjjlw3QAml1Bi6FU4TVO8WNrZsYJL cEno42UrX8z4ZAi9xDaubZbLQUon4WwvLCVog2bTNuAlA0a42AyuEGS37J2dGJS6Y0gvNTdu8yj KpFUoXLv3bsdGCDTO95XLGT98RVkJzX3jzicXOPxH4WQkzPBjzzg2XQ== X-Gm-Gg: AYBFou2TVz7IldwBKIf5cXr6LW4Wd4aUL5ldl3bzToR7joIov/At6bq49jegspsoyP5 JgwjyP/WeJMhE6BXdv6VAXPb2a3TDfLqBu2qdtUXNqBf2isVWnOMd7zpJlPLELcUmQ45Jl0zIi8 71AgJaJLV/i43IIBkgYk4VH6Sbr7xdD3qN8dX1HPq+ZSjg6MttJLXN82VkT3kf7HzPh96R6XxHp neQeJy6zS0BGgztuy2whAKCSYeQmD5z7Ir+YLsFtLa8B+OKsaXJ029ydzWFLay45+zbHNeSOJLu CQgNcFFnzQQc/bfoP/An70jjK++HIpSOAqYipfzghg5P35S6jZ+UDPX8RaHbe1amZinBng+yhKK QyFjpSna+GQ== X-Received: by 2002:a5d:5e86:0:b0:48e:adc:b97d with SMTP id ffacd0b85a97d-48e1e7a7a2emr7984740f8f.8.1792540617025; Tue, 20 Oct 2026 16:56:57 -0700 (PDT) X-Received: by 2002:a5d:5e86:0:b0:48e:adc:b97d with SMTP id ffacd0b85a97d-48e1e7a7a2emr7984707f8f.8.1792540616476; Tue, 20 Oct 2026 16:56:56 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e254f0bc2sm1617247f8f.1.2026.10.20.16.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2026 16:56:55 -0700 (PDT) From: Stefano Brivio To: Martin Schitter Subject: Re: [PATCH v2 1/3] Fix handling of netlink multipart route dumps. Message-ID: <20261021015654.0a7f5e12@elisabeth> In-Reply-To: References: <20260908181631.537802-1-ms+git@mur.at> <20260908181631.537802-2-ms+git@mur.at> <20260917210812.44e10453@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 21 Oct 2026 01:56:55 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ItDnXM8qBUDDwtXjLdeuuL111XLFf2vgZb89vmf0Puc_1792540617 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GNDEVPUWROC42EXMTZPZJVBZ355C7Z6W X-Message-ID-Hash: GNDEVPUWROC42EXMTZPZJVBZ355C7Z6W 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 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: I just replied to your v4, some left-over comments from here that might still be relevant: On Sat, 19 Sep 2026 14:56:36 +0200 Martin Schitter wrote: > On 9/17/26 21:08, Stefano Brivio wrote: > > > > [...] > > > > Here, and in following patches: missing Signed-off-by: tag (see > > CONTRIBUTING.md). > > o.k. I'll add it -- although I'm not convinced that it makes much sense > in a modern jj based patch description workflow. jj meaning... Jujutsu? But we don't use it? Anyway, the idea behind it is described here: https://www.kernel.org/doc/html/next/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin ...it's not so much about the workflow. It's about a concise way of certifying all that, and it might be something we'll need at some point in the future. > > [...] > > > >> + nh = nl_next(s, &buf[collected], NULL, &n); > >> + debug("collect: add chunk of size n=%ld at offset=%ld, seq=%d nlmsg_len=%d", > >> + n, collected, seq, ((const struct nlmsghdr *)&buf[collected])->nlmsg_len); > > > > At some point, we should get a netlink monitor (see > > https://bugs.passt.top/show_bug.cgi?id=141) which might run this function > > quite frequently at runtime, and having this as debug() message would > > risk flooding debug logs and making them otherwise unusable. > > You can eliminate all my debug print commands just as you like. > > But as long as we do not have suitable unit tests to control at least a > subset of common cases in advance, debug logs could be very helpful to > iron out remaining mistakes and false assumptions. Well, you can create tests if you want (see test/README.md). Not unit tests, but you could easily build a test building a large number of routes (within a pasta environment) and then run pasta --config-net into it. And yes, I don't doubt of the value this kind of debug print, but still the downsides seems to outweigh the benefits in this case. > btw.: I don't think you should run this kind of routines frequently. I don't expect we'll need to duplicate hundreds of routes per second, so that's not the kind of overhead I meant. It's mostly routes coming and going frequently and spamming logs. > Kernel-userspace-transfers are rather expensive. Perhaps you could try > to utilize eBPF to handle these route table duplication resp. transfer > between namespaces in a more efficient manner. No root, no eBPF. That's kind of the whole point of this project. :) > > I think we could consider trace(). My preference would actually to drop > > this altogether because it seems to be specific to some particular > > phase of your development and not something of general relevance. > > That's o.k. for me. > > But please consider, that we do not have much control about many details > of the actual kernel behavior in respect to this complex netlink > multipart dumps. It can be rather challenging to reproduce and solve all > related issues without useful debug log capabilities. Yeah, I see, on the other hand if users report something specific they can also try out a special build with added debugging. > > If we want to keep this for some reason: "collect" isn't very > > descriptive (mind that it will just be printed among other messages > > coming from completely different parts of the code). I would rather use > > __func__. > > __func__ and similar more precise code location prefixes would IMHO make > the output even more dense, confusing, and cluttering. Maybe it doesn't look good, but at least it tells you what it is about, instead of "collect:". -- Stefano