KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated. See the issue reported in [1] where users
have to set USERCFLAGS instead, which shouldn't be needed.

The kselftest doc [2] recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.

Other net targets have KHDR_INCLUDES added to their CFLAGS.

Link: https://lore.kernel.org/275ba183-49fd-45b1-881d-0f362b4c74c0@ovn.org [1]
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details [2]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Note: this series is targeting net to help CI and devs validating Linus
tree or the stable ones. These are not critical fixes for the kernel,
but still useful for the tests. If preferred, the series can be applied
on net-next.

---
Matthieu Baerts (NGI0) (2):
      selftests: netfilter: use KHDR_INCLUDES in CFLAGS
      selftests: forwarding: use KHDR_INCLUDES in CFLAGS

 tools/testing/selftests/net/forwarding/Makefile | 2 ++
 tools/testing/selftests/net/netfilter/Makefile  | 2 ++
 2 files changed, 4 insertions(+)
---
base-commit: 641d03105cc0d2437e32fdeec164f91a4ccef6c4
change-id: 20260904-net-sft-nf-khdr_includes-07aa6b61143d

Best regards,
--  
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Jakub,

On 04/09/2026 18:13, Matthieu Baerts (NGI0) wrote:
> KHDR_INCLUDES is typically used to include headers from the kernel
> source directory instead of only relying on the ones from the host: they
> can be missing or outdated. See the issue reported in [1] where users
> have to set USERCFLAGS instead, which shouldn't be needed.
> 
> The kselftest doc [2] recommends assigning KHDR_INCLUDES to CFLAGS in a
> target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
> $(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
> was built in a different build directory.
> 
> Other net targets have KHDR_INCLUDES added to their CFLAGS.

These patches didn't get picked up in the tests because the Clang build
failed with Rust code:

https://netdev-ctrl.bots.linux.dev/logs/build/1158213/14791779/build_clang/stderr

I only modified the selftests here. Other patches sent before me have
the same issue, but some sent after don't. One of those "random" issues
on the build server?

Cheers,
Matt

On Fri, 4 Sep 2026 20:20:44 +0200 Matthieu Baerts wrote:
> These patches didn't get picked up in the tests because the Clang build
> failed with Rust code:
> 
> https://netdev-ctrl.bots.linux.dev/logs/build/1158213/14791779/build_clang/stderr
> 
> I only modified the selftests here. Other patches sent before me have
> the same issue, but some sent after don't. One of those "random" issues
> on the build server?

kbuild / tools build likes to sometimes pick up the wrong source tree
if you have a worktree nested inside a git repo :/
Here the Rust build was partially using the sources from the main repo
and partially from the work tree.
I'll push a NIPA workaround to sync the main repo to something recent
it should paper over this bug. It's not the first time it happened.

Hi Jakub,

On 04/09/2026 20:51, Jakub Kicinski wrote:
> On Fri, 4 Sep 2026 20:20:44 +0200 Matthieu Baerts wrote:
>> These patches didn't get picked up in the tests because the Clang build
>> failed with Rust code:
>>
>> https://netdev-ctrl.bots.linux.dev/logs/build/1158213/14791779/build_clang/stderr
>>
>> I only modified the selftests here. Other patches sent before me have
>> the same issue, but some sent after don't. One of those "random" issues
>> on the build server?
> 
> kbuild / tools build likes to sometimes pick up the wrong source tree
> if you have a worktree nested inside a git repo :/
> Here the Rust build was partially using the sources from the main repo
> and partially from the work tree.
> I'll push a NIPA workaround to sync the main repo to something recent
> it should paper over this bug. It's not the first time it happened.

Thank you for the explanation, and for the fix!

I was checking if I had to resend this series for the CI, but it looks
like these patches have been taken by the "brancher" service, e.g.

- https://github.com/linux-netdev/testing/commit/93408c0627c0
- https://github.com/linux-netdev/testing/commit/82fe019a07b0

Maybe they are there after the few hickups due to PW's update?

(It is not clear why it says there is a conflict, but I guess that's
because the contest job didn't override the status for the same reasons.)

Anyway, no need to re-send them then. Or should I?

Cheers,
Matt