Re: [LTP] lib: Rename function check_kver() => check_min_kver()

Hi all,

> 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.

Hm, I'm not sure if that's needed

> --- [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.

Ah, thanks! Before merge I'll amend:

- * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
+ * on any stable release (test with ``max_kver = "7.1"`` runs also on kernel

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

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

Ah, thanks! Before merge I'll amend:

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

> --- [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.

@Cyril @Andrea could you also please double check?

> --- [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.

@Cyril @Andrea could you also please double check?

> --- [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.

Hm, do we care when Amir is ok with it?

Kind regards,
Petr

> > +	.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