Re: lib: Rename function check_kver() => check_min_kver()

Hi Petr,

On Fri, 31 Jul 2026, Petr Vorel wrote:
> lib: Rename function check_kver() => check_min_kver()

--- [PATCH 1/5] ---

> Preparation for a next commit.

Could the message explain that the rename distinguishes the minimum-version
helper from the new maximum-version helper, without referring to a later
patch? The current body does not explain the change independently.

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

> + * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
> + * 7.1.5). Stable releases are compared as expected.

Could this example use ``max_kver``? As written, the new field documents the
opposite API.

> +	for (i=0, dots=0; max_kver[i]; i++)

Could spaces be added around both assignment operators to follow kernel
coding style?

--- [PATCH 3/5] ---

> +	.max_kver = "6.10",

Could this test be allowed to run again on Linux 7.2? In that tree,
do_open_execat() calls exe_file_deny_write_access() and returns ETXTBSY when
the executable is open for writing (fs/exec.c:800-802).

A permanent maximum version therefore reports TCONF for behavior that is
valid again. It cannot represent the temporary 6.11 through 7.1 behavior
window.

--- [PATCH 4/5] ---

> +	.max_kver = "6.10",

Could creat07 also be allowed to run again on Linux 7.2? The exec path makes
i_writecount negative through exe_file_deny_write_access(), and creat() then
reaches get_write_access(), which returns ETXTBSY for a negative count
(include/linux/fs.h:2813-2816).

This maximum bound suppresses valid 7.2 coverage and cannot describe the
temporary 6.11 through 7.1 behavior window.

--- [PATCH 5/5] ---

> Because the above flag combinations are already "tested" by the tests
> that use them and we don't have any tests that >= 5.10 has support for
> FAN_MARK_FILESYSTEM etc just simply skip the test on v7.2.

Could this claim be corrected? Other tests exercise FAN_REPORT_TID and
FAN_REPORT_PIDFD separately, but fanotify20 is the only LTP test combining
them.

> +	.max_kver = "7.1",

Could the first case instead expect success when thread pidfds are supported,
while retaining the second valid-combination check? Linux 7.2 now uses
task_pid(current) for FAN_REPORT_TID and creates a thread pidfd
(fs/notify/fanotify/fanotify.c:843-849 and
fs/notify/fanotify/fanotify_user.c:906-913). Skipping the whole test removes
the only coverage of the newly valid combination.

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp