[LTP] tst_kconfig: add module mappings for ingress/matchall/pedit

[linuxtestproject.agent@gmail.com]

Hi Andrea,

On Mon, Jul 20 2026, Andrea Cervesato wrote:
> tst_kconfig: add module mappings for ingress/matchall/pedit

--- [PATCH 1/2] ---

> Map CONFIG_NET_SCH_INGRESS, CONFIG_NET_CLS_MATCHALL and CONFIG_NET_ACT_PEDIT
> to their kernel modules (sch_ingress, cls_matchall, act_pedit).

The body restates what the subject already says. Is there a sentence
missing that explains what prompted these additions -- e.g. that the
following patch (cve-2026-46331) needs them for the kconfig module
check to work when the features are built as modules?

--- [PATCH 2/2] ---

> +	for (unsigned int i = 0; i < ARRAY_SIZE(mods); i++)
> +		tst_modprobe(mods[i], NULL);
> +
> +	/* Drop privileges so the reproducer runs as an unprivileged user */
> +	pw = SAFE_GETPWNAM("nobody");
> +	SAFE_SETGID(pw->pw_gid);
> +	SAFE_SETUID(pw->pw_uid);

The three modules loaded by tst_modprobe() are never unloaded. cleanup()
has no matching tst_module_unload() calls, so sch_ingress, cls_matchall
and act_pedit remain in the kernel after the test exits.

The constraint is structural: SAFE_SETUID() permanently drops root, so
cleanup() runs as "nobody" and cannot call rmmod even if the call were
added there.

Is the expectation that these modules are present on any system running
this test, making the omission intentional? If so, a short comment in
cleanup() noting that module unload is skipped because privileges have
been dropped would make the intent clear.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer