rtpengine version the issue has been seen with
mr26.2.1.1
Used distribution and its version
No response
Linux kernel version used
No response
CPU architecture issue was seen on (see uname -m)
None
Expected behaviour you didn't see
Environment: RHEL 9 family, kernel 5.14.0-70.22.1.el9_0.x86_64, matching kernel-devel headers confirmed present and correct.
Steps: git checkout → cd kernel-module && make clean && make, tried on master, mr26.2.1.1, and mr26.1.1.10.
Error 1 (all three): implicit declaration of function 'eventfd_signal_mask' in ring_buffer_insert.
Error 2 (all three): .dump = rtpengine_expr_dump — incompatible pointer type, kernel expects 3-arg (struct sk_buff *, const struct nft_expr *, bool), code provides 2-arg, for rtpengine_inet_ops, rtpengine_ipv4_ops, rtpengine_ipv6_ops.
Investigation: gen-rtpengine-kmod-flags (the build's own kernel-API auto-detection script) contains a real compile-test for nft_expr_ops.validate's signature (NFT_EXPR_OPS_VALIDATE_HAS_DATA), with a comment explaining distro kernels backport APIs without bumping LINUX_VERSION_CODE, so a compile-test is required rather than a version check. Confirmed via git show master:kernel-module/gen-rtpengine-kmod-flags | grep -i "dump|reset" — no equivalent detection exists for .dump, on master or either tag tried. Commit 503c4aa ("Fix nft_rtpengine compilation on RHEL/AlmaLinux 9.x kernel 5.14") addresses this exact symptom but doesn't appear to activate on this kernel — possibly because .dump's variant selection relies on a LINUX_VERSION_CODE check rather than a compile-test, which would fail for the same backporting reason .validate already accounts for.
Unexpected behaviour you saw
No response
Steps to reproduce the problem
No response
Additional program output to the terminal or logs illustrating the issue
Anything else?
No response
rtpengine version the issue has been seen with
mr26.2.1.1
Used distribution and its version
No response
Linux kernel version used
No response
CPU architecture issue was seen on (see
uname -m)None
Expected behaviour you didn't see
Environment: RHEL 9 family, kernel 5.14.0-70.22.1.el9_0.x86_64, matching kernel-devel headers confirmed present and correct.
Steps: git checkout → cd kernel-module && make clean && make, tried on master, mr26.2.1.1, and mr26.1.1.10.
Error 1 (all three): implicit declaration of function 'eventfd_signal_mask' in ring_buffer_insert.
Error 2 (all three): .dump = rtpengine_expr_dump — incompatible pointer type, kernel expects 3-arg (struct sk_buff *, const struct nft_expr *, bool), code provides 2-arg, for rtpengine_inet_ops, rtpengine_ipv4_ops, rtpengine_ipv6_ops.
Investigation: gen-rtpengine-kmod-flags (the build's own kernel-API auto-detection script) contains a real compile-test for nft_expr_ops.validate's signature (NFT_EXPR_OPS_VALIDATE_HAS_DATA), with a comment explaining distro kernels backport APIs without bumping LINUX_VERSION_CODE, so a compile-test is required rather than a version check. Confirmed via git show master:kernel-module/gen-rtpengine-kmod-flags | grep -i "dump|reset" — no equivalent detection exists for .dump, on master or either tag tried. Commit 503c4aa ("Fix nft_rtpengine compilation on RHEL/AlmaLinux 9.x kernel 5.14") addresses this exact symptom but doesn't appear to activate on this kernel — possibly because .dump's variant selection relies on a LINUX_VERSION_CODE check rather than a compile-test, which would fail for the same backporting reason .validate already accounts for.
Unexpected behaviour you saw
No response
Steps to reproduce the problem
No response
Additional program output to the terminal or logs illustrating the issue
Anything else?
No response