Re: [PATCH] tc: fix build failure with Linux >= 6.8 kernel headers (CBQ removal)

Hi,

Le mar. 18 août 2026 à 12:26, Guillermo Rodriguez Garcia via busybox
<[email protected]> a écrit :
>
> El mar, 18 ago 2026 a las 11:55, Michael Tokarev via busybox
> (<[email protected]>) escribió:
> >
> > On 8/17/26 00:55, tito via busybox wrote:
> >
> > > as far as I understand with the proposed fix the
> > > tc applet will only work with the kernel it is compiled with,
> > > if you use a busybox tc applet compiled with kernel 6.12.103
> > > it will not work with 6.7.0 and cbq , this could be seen as a shortcoming.
> > > Please take a look at my proposed patch which fixes building
> > > busybox and allows use with all kernels at the expense
> > > of a little size increase.
> >
> > If you build your busybox with recent kernel headers (it has nothing
> > to do with the kernel, only kernel headers actually matters), - it is
> > unlikely you'll run it on outdated kernels.  And even on kernel 6.7,
> > this subsystem were deprecated already.  So personally, I see no reason
> > to keep building something when it's clear it wont be used.
>
> In embedded systems, where busybox is widely used, it is actually
> quite common for the toolchain, including the kernel headers it
> provides, to be older than the kernel running on the target.
> Toolchains tend to have a much longer lifetime and are not necessarily
> updated together with the target kernel.

I don't think this should be encouraged. At the very minimum, the libc
shall be built using the headers of your target kernel, and your
toolchain might be otherwise up to date. I understand that this is not
always possible but when it is, this should be the default settings
(nobody wants to build a software as important as busybox against a
tool chain with known vulnerabilities, especially when the goal is to
push busybox on an embedded platform).

> I think it makes sense for busybox built against older kernel headers
> to remain usable with newer kernels, and vice-versa where possible.

Building busybox against the header of a newer kernel might produce
binaries that cannot run on an older kernel -- new system calls, new
flag values... might be removed or introduced and used in the possibly
statically linked libc.  Linux (tries to) make sure that a binary you
build on an old version of Linux will still run on a newer version,
but it does not guarantee you the other way - and this is especially
true if you add another layer of indirection such as a libc (extreme
case in point: glibc's open(3) uses openat(2) that might not be
present on an older system (kernel version < 2.6.16 ; yeah, I said
"extreme" :D )).

In this case, a busybox binary compiled against older headers might
work on a newer kernel - although I have a hard time following what
parse_rtattr() would do in this case, so I would not assume that it
indeed works, and maybe some more tests are required here (the fact
that the constants were present and allowed programs to be compiled
and work without the underlying CBQ code in the kernel would indicate
that the busybox code might work in this case).

Do we really want to make the claim that a busybox binary compiled on
a recent kernel will also work as expected when executed on an older
kernel? In my opinion, this is not a good idea. If you agree with me
then the form of the patch (not the patch itself, I did not try to
judge it) might be good enough (with the caveat outlined in the
previous paragraph) ; if it is expected that a binary compiled with
the 6.8 kernel headers displays the CBQ information when executed on
kernel <6.3 then the patch is not enough. But again, in my opinion,
this is not a good idea.

> Best regards,
>
> Guillermo Rodriguez Garcia
> [email protected]

Best regards,

-- Emmanuel Deloget
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox