Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

nft_expr_ops.dump signature not covered by kernel-module build detection — fails on RHEL9/kernel 5.14, reproduces on master, mr26.2.1.1, and mr26.1.1.10

Open
  • Is something wrong?
#2,162 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c, linux
Domain
build-system

Research direction

The kernel-module build auto-detects API variants in kernel-module/gen-rtpengine-kmod-flags; read the existing NFT_EXPR_OPS_VALIDATE_HAS_DATA compile-test there and commit 503c4aa as the pattern to follow. The .dump mismatch surfaces in the nft_expr_ops initialisers for rtpengine_inet_ops, rtpengine_ipv4_ops and rtpengine_ipv6_ops, while eventfd_signal_mask is used in ring_buffer_insert. Done looks like a clean kernel-module make on RHEL9 5.14 that selects the 3-arg dump signature without breaking kernels that still use the 2-arg one.

Written by the indexing model from the issue text.

Description

bug
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

Dominant language
Perl
Stars
992
Forks
459
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipwise/rtpengine

All issues in sipwise/rtpengine

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.