Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#2,162 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
c, linux
領域
build-system

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Perl
スター
992
フォーク
459
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sipwise/rtpengine のほかの issue

sipwise/rtpengine の issue をすべて見る

似ている issue

Perl の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。