From: linuxtestproject.agent@gmail.com
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] tst_kvercmp: Factor out error handling
Date: Wed, 5 Aug 2026 17:34:57 +0000 [thread overview]
Message-ID: <20260805173457.4172-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260805151451.648990-2-pvorel@suse.cz>
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
next prev parent reply other threads:[~2026-08-05 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 15:14 [LTP] [PATCH v4 0/6] Add support for .max_kver Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 1/9] tst_kvercmp: Factor out error handling Petr Vorel
2026-08-05 17:33 ` [LTP] " linuxtestproject.agent
2026-08-05 17:33 ` linuxtestproject.agent
2026-08-05 17:34 ` linuxtestproject.agent [this message]
2026-08-05 17:35 ` linuxtestproject.agent
2026-08-10 12:02 ` Petr Vorel
2026-08-06 7:02 ` [LTP] [PATCH v4 1/9] " Andrea Cervesato via ltp
2026-08-10 11:33 ` Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 2/9] lib: Rename function check_kver() => check_min_kver() Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 3/9] lib: Add support for max_kver to struct tst_test and tst_fs Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 4/9] creat07: execve04: Remove version check, add linux-git Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 5/9] fanotify20: Skip on v7.2 Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 6/9] lib: Add basic test for .min_kver && .max_kver Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 7/9] tst_kvercmp: Factor out 2 kernels integer comparison Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 8/9] [RFC] make: Allow to add LTP library as a dependency for host Petr Vorel
2026-08-05 15:14 ` [LTP] [PATCH v4 9/9] [RFC] metaparse: Check {min, max}_kver validity Petr Vorel
2026-08-06 5:37 ` Petr Vorel
2026-08-06 7:23 ` Cyril Hrubis
2026-08-10 11:23 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805173457.4172-1-linuxtestproject.agent@gmail.com \
--to=linuxtestproject.agent@gmail.com \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox