[LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent@gmail.com]

Hi Petr,

On Mon, Aug 10, 2026, Petr Vorel wrote:
> [PATCH 1/7] tst_kvercmp: Factor out error handling

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

> This is a preparation for struct tst_test max_kver member in the next
> commit.

Could this avoid referring to the next patch so that the commit message is
self-contained? For example, it could say that the rename makes room for a
corresponding maximum kernel-version check.

--- [PATCH 3/7] ---

> NOTE: Mainline release is sufficient on any stable release (test with
> .min_kver = "7.1" runs also on kernel 7.1.5). Stable releases are
> compared as expected.

Should this say ".max_kver" instead? This paragraph documents the new maximum
version semantics, and the corresponding header uses max_kver.

--- [PATCH 6/7] ---

> static struct tst_test test = {
> 	.setup = do_setup,
> +	.max_kver = "7.1",
> 	.test = do_test,

Could the changed PIDFD/TID expectation be handled without skipping the whole
test on 7.2? The second case,
FAN_REPORT_PIDFD | FAN_REPORT_FID | FAN_REPORT_DFID_NAME, is still a valid
success case in the 7.2 fanotify_init() implementation, and no other LTP test
uses that exact combination. The newly supported PIDFD/TID combination is not
exercised elsewhere either.

--- [PATCH 7/7] ---

> + * Basic test to test that .min_kver and .max_kver can be used together.
> + * Test should TCONF or TPASS.

Could this test use bounds that make TPASS deterministic? runtest.sh accepts
both TPASS and TCONF, so a regression that always rejects tests whenever both
fields are set still leaves this self-test green. On kernels newer than 7.2,
the callback is not exercised at all.

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