netdev - Re: [PATCH net-next] net: reorganize IP MIB values (II)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1c8949c99d61ebf9f3882397d146213c5c519a75.camel@gmail.com>
Date: Fri, 12 Dec 2025 00:38:54 +0100
From: Thomas Haller <thom311@...il.com>
To: Eric Dumazet <edumazet@...gle.com>, "David S . Miller"
 <davem@...emloft.net>,  Jakub Kicinski	 <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>
Cc: Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next] net: reorganize IP MIB values (II)

On Thu, 2025-03-20 at 10:14 +0000, Eric Dumazet wrote:
> Commit 14a196807482 ("net: reorganize IP MIB values") changed
> MIB values to group hot fields together.
> 
> Since then 5 new fields have been added without caring about
> data locality.
> 
> This patch moves IPSTATS_MIB_OUTPKTS, IPSTATS_MIB_NOECTPKTS,
> IPSTATS_MIB_ECT1PKTS, IPSTATS_MIB_ECT0PKTS, IPSTATS_MIB_CEPKTS
> to the hot portion of per-cpu data.


Hi,


the patch

 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=652e2c777862c869966082fec98174640ab20dc9

reorders the enum values in the user space header.
It's not only done by this patch, for example also
b4a11b2033b7d3dfdd46592f7036a775b18cecd1.
Similarly, the `LINUX_MIB_*` enums keep changing.

This seems problematic to me. For example, iproute2 does:

  https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/lib/utils.c?id=24a5a424e3a0b3d85dd035540d874dd769ecb2d3#n1536

which only works as long as the kernel headers (at compile time) are in
sync with the running kernel. That is often not the case, for example
with containers.

libnl3 also is affected and tries to (badly) workaround this: 

  https://github.com/thom311/libnl/commit/5981a39583ab65dca230a8ee70625626d9ec9fc8


How do you suggest should API users handle this? In the future, would
it be possible to keep the API stable and backward compatible?


Thank you,
Thomas