Re: tst_kvercmp: Factor out error handling

Hi all,

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

I would not really bother with it.

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

Yes, I need to amend the commit message before merging.

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

No, kernel maintainers are ok with it as changing the test would be a bit complicated
(and I've been mentioning this on every version).

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

Well, last time I had old version and it asked for 7.2. Anyway, this was exactly
the reason why I had 5.0 last time. I can change to whatever version somebody
suggests, maybe going back to 5.0 would be good.

> 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