Re: tst_kvercmp: Factor out error handling

Hi Petr,

On Wed, 5 Aug 2026, Petr Vorel wrote:
> tst_kvercmp: Factor out error handling

--- [PATCH 1/9] ---

> +static int _tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)

Could this helper use an unreserved name such as parse_kver()?
Identifiers beginning with an underscore are reserved at file scope and are
explicitly disallowed by the LTP C coding rules.

--- [PATCH 4/9] ---

> +	if (TST_RET != -1) {
> +		tst_res(TFAIL, "creat() succeeded unexpectedly");
> +		return;
> +	}

Could this path kill and reap pid before returning? This patch exposes the
path on affected 6.11 and 6.12 kernels, but the child remains executing
creat07_child. run_tests() then blocks in tst_reap_children() instead of
finishing with the reported TFAIL, and the test eventually times out.

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

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

Could only the FAN_REPORT_PIDFD | FAN_REPORT_TID case be adjusted or omitted
on 7.2 and newer? The second case remains valid, and no other fanotify C test
initializes a group with FAN_REPORT_PIDFD | FAN_REPORT_FID |
FAN_REPORT_DFID_NAME. Since 7.2 is already stable, gating the whole test
immediately removes that coverage on current kernels.

--- [PATCH 6/9] ---

> +static struct tst_test test = {
> +	.min_kver = "4.4",
> +	.max_kver = "5.0",
> +	.test_all = do_test,
> +};

Could the bounds include kernels used by current CI? On stable 7.2, and every
kernel newer than 5.0.x, the library exits with TCONF before do_test() runs.
The test therefore does not perform the CI check described by the commit
message.

--- [PATCH 9/9] ---

> +	if (min_kver && max_kver) {
> +		if (tst_kver_cmp(a1, a2, a3, b1, b2, b3) < 0) {

Could this validation use the same two-component maximum semantics as
check_max_kver()? For example, min_kver "7.1.5" and max_kver "7.1" form a
valid interval because max_kver "7.1" permits every 7.1.x kernel, but this
comparison rejects it as min_kver greater than max_kver.

> +include $(top_srcdir)/include/mk/testcases.mk
> +metaparse: HOST_LDLIBS		+= -lltp

Could the required helpers instead be compiled with HOSTCC? testcases.mk
builds libltp.a with the target CC, while metaparse is linked with HOSTCC.
During cross compilation, the target objects cannot be linked into the host
executable, so metadata generation fails with an incompatible object format.

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