[LTP] [PATCH v5 0/7] Add support for .max_kver

[LTP] [PATCH v5 0/7] Add support for .max_kver

[Petr Vorel]

Hi all,

Changes v4->v5:
* Remove code which does metadata validation (3 commits, Cyril).
* Add commit to fix creat07.c timeout on test failure (agent).
* Use proper name for function (underscore at the end)
* Add one more test, increase max_kver in the test added previous
  version.

Link to v4:
https://lore.kernel.org/ltp/20260805151451.648990-1-pvorel@suse.cz/

Link to v3:
https://patchwork.kernel.org/project/ltp/list/?series=1138093&state=*
https://lore.kernel.org/ltp/20260731105132.187177-1-pvorel@suse.cz/T/#t

Link to v2:
https://lore.kernel.org/ltp/6a6a2091.9b80fa5d.4e4ae.7aac@mx.google.com/T/#t

Link to v1:
https://lore.kernel.org/ltp/20260729091717.23042-1-pvorel@suse.cz/T/#t
https://patchwork.ozlabs.org/project/ltp/list/?series=516120&state=*


Petr Vorel (7):
  tst_kvercmp: Factor out error handling
  lib: Rename function check_kver() => check_min_kver()
  lib: Add support for max_kver to struct tst_test and tst_fs
  creat07: Avoid timeout on the test failure
  creat07: execve04: Remove version check, add linux-git
  fanotify20: Skip on v7.2
  lib: Add 2 basic tests for .min_kver && .max_kver

 doc/developers/writing_tests.rst              |  3 +
 include/tst_test.h                            | 13 +++-
 lib/newlib_tests/.gitignore                   |  2 +
 lib/newlib_tests/runtest.sh                   |  2 +
 lib/newlib_tests/tst_max_kver_old.c           | 21 +++++++
 lib/newlib_tests/tst_min_kver_max_kver.c      | 22 +++++++
 lib/tst_kvercmp.c                             | 23 ++++++--
 lib/tst_test.c                                | 59 +++++++++++++++----
 testcases/kernel/syscalls/creat/creat07.c     | 23 ++++----
 testcases/kernel/syscalls/execve/execve04.c   | 24 ++++----
 .../kernel/syscalls/fanotify/fanotify20.c     |  4 ++
 11 files changed, 156 insertions(+), 40 deletions(-)
 create mode 100644 lib/newlib_tests/tst_max_kver_old.c
 create mode 100644 lib/newlib_tests/tst_min_kver_max_kver.c

-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 1/7] tst_kvercmp: Factor out error handling

[Petr Vorel]

Error check was already on 2 places (and possibly more will be added in
the future).

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Changes v1->v2:
* Use proper name for function (underscore at the end)

 lib/tst_kvercmp.c | 23 +++++++++++++++++------
 lib/tst_test.c    |  6 +-----
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/lib/tst_kvercmp.c b/lib/tst_kvercmp.c
index 9e1a511aff..27b156c8bc 100644
--- a/lib/tst_kvercmp.c
+++ b/lib/tst_kvercmp.c
@@ -45,7 +45,7 @@ static char *parse_digit(const char *str, int *d)
 	return end;
 }
 
-int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
+static int tst_parse_kver_(const char *str_kver, int *v1, int *v2, int *v3)
 {
 	const char *str = str_kver;
 
@@ -81,17 +81,28 @@ int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
 	return 0;
 }
 
-int tst_kvcmp(const char *cur_kver, int r1, int r2, int r3)
+int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
 {
-	int a1, a2, a3;
-	int testver, currver;
+	int rc;
+
+	rc = tst_parse_kver_(str_kver, v1, v2, v3);
 
-	if (tst_parse_kver(cur_kver, &a1, &a2, &a3)) {
+	if (rc) {
 		tst_resm(TWARN,
 			 "Invalid kernel version %s, expected %%d.%%d.%%d",
-		         cur_kver);
+		         str_kver);
 	}
 
+	return rc;
+}
+
+int tst_kvcmp(const char *cur_kver, int r1, int r2, int r3)
+{
+	int a1, a2, a3;
+	int testver, currver;
+
+	tst_parse_kver(cur_kver, &a1, &a2, &a3);
+
 	testver = (r1 << 20) + (r2 << 10) + r3;
 	currver = (a1 << 20) + (a2 << 10) + a3;
 
diff --git a/lib/tst_test.c b/lib/tst_test.c
index 9c5f2617fe..a147521e9d 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1067,11 +1067,7 @@ static bool check_kver(const char *min_kver, const int brk_nosupp)
 	char *msg;
 	int v1, v2, v3;
 
-	if (tst_parse_kver(min_kver, &v1, &v2, &v3)) {
-		tst_res(TWARN,
-			"Invalid kernel version %s, expected %%d.%%d.%%d",
-			min_kver);
-	}
+	tst_parse_kver(min_kver, &v1, &v2, &v3);
 
 	if (tst_kvercmp(v1, v2, v3) < 0) {
 		msg = "The test requires kernel %s or newer";
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent]

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] tst_kvercmp: Factor out error handling

[Petr Vorel]

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

Re: [LTP] [PATCH v5 1/7] tst_kvercmp: Factor out error handling

[Andrea Cervesato via ltp]

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 2/7] lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

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

Reviewed-by: Avinesh Kumar <avinesh.kumar@suse.com>
Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
The same as in v4.

 lib/tst_test.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/tst_test.c b/lib/tst_test.c
index a147521e9d..5e64fb5b63 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1058,11 +1058,11 @@ static void do_exit(int ret)
 }
 
 /*
- * Check for the required kernel version.
+ * Check for the minimal required kernel version.
  *
  * return: true if the kernel version is high enough, false otherwise.
  */
-static bool check_kver(const char *min_kver, const int brk_nosupp)
+static bool check_min_kver(const char *min_kver, const int brk_nosupp)
 {
 	char *msg;
 	int v1, v2, v3;
@@ -1457,7 +1457,7 @@ static void do_setup(int argc, char *argv[])
 		tst_brk(TCONF, "Test needs to be run as root");
 
 	if (tst_test->min_kver)
-		check_kver(tst_test->min_kver, 1);
+		check_min_kver(tst_test->min_kver, 1);
 
 	if (tst_test->skip_in_lockdown && tst_lockdown_enabled() > 0)
 		tst_brk(TCONF, "Kernel is locked down, skipping test");
@@ -1580,7 +1580,7 @@ static void do_setup(int argc, char *argv[])
 				tst_check_cmd(tst_test->filesystems->mkfs_ver, 1);
 
 			if (tst_test->filesystems && tst_test->filesystems->min_kver)
-				check_kver(tst_test->filesystems->min_kver, 1);
+				check_min_kver(tst_test->filesystems->min_kver, 1);
 
 			prepare_device(tst_test->filesystems);
 		}
@@ -1984,7 +1984,7 @@ static void run_tcase_on_fs(struct tst_fs *fs, const char *fs_type)
 	if (fs->mkfs_ver && !tst_check_cmd(fs->mkfs_ver, 0))
 		return;
 
-	if (fs->min_kver && !check_kver(fs->min_kver, 0))
+	if (fs->min_kver && !check_min_kver(fs->min_kver, 0))
 		return;
 
 	prepare_device(fs);
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 3/7] lib: Add support for max_kver to struct tst_test and tst_fs

[Petr Vorel]

max_kver adds a support to require a maximal kernel version the test can
run on. e.g. "7.2" (mainline release) or "6.1.180" (stable release).

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.

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
The same as in v4.

 doc/developers/writing_tests.rst |  3 +++
 include/tst_test.h               | 13 +++++++++-
 lib/tst_test.c                   | 43 ++++++++++++++++++++++++++++++++
 3 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/doc/developers/writing_tests.rst b/doc/developers/writing_tests.rst
index 0edf101ff9..d3f5800730 100644
--- a/doc/developers/writing_tests.rst
+++ b/doc/developers/writing_tests.rst
@@ -404,6 +404,9 @@ LTP C And Shell Test API Comparison
     * - .min_kver
       - TST_MIN_KVER
 
+    * - .max_kver
+      - not implemented
+
     * - .min_mem_avail
       - not applicable
 
diff --git a/include/tst_test.h b/include/tst_test.h
index c69362485e..30c32b844e 100644
--- a/include/tst_test.h
+++ b/include/tst_test.h
@@ -280,6 +280,9 @@ struct tst_ulimit_val {
  *
  * @min_kver: A minimum kernel version supporting the filesystem which has been
  *            created with mkfs.
+ *
+ * @max_kver: A maximum kernel version supporting the filesystem which has been
+ *            created with mkfs.
  */
 struct tst_fs {
 	const char *type;
@@ -292,6 +295,7 @@ struct tst_fs {
 	const void *mnt_data;
 
 	const char *min_kver;
+	const char *max_kver;
 };
 
 /**
@@ -301,7 +305,13 @@ struct tst_fs {
  *        and each time passed an increasing counter value.
  * @options: An NULL optstr terminated array of struct tst_option.
  *
- * @min_kver: A minimal kernel version the test can run on. e.g. "3.10".
+ * @min_kver: A minimal kernel version the test can run on. e.g. "4.4" (mainline
+ * release) or "6.1.180" (stable release).
+ *
+ * @max_kver: A maximal kernel version the test can run on. e.g. "7.2" (mainline
+ * release) or "6.1.180" (stable release). NOTE: Mainline release is sufficient
+ * on any stable release (test with ``max_kver = "7.1"`` runs also on kernel
+ * 7.1.5). Stable releases are compared as expected.
  *
  * @supported_archs: A NULL terminated array of architectures the test runs on
  *                   e.g. {"x86_64, "x86", NULL}. Calls tst_is_on_arch() to
@@ -551,6 +561,7 @@ struct tst_fs {
 	struct tst_option *options;
 
 	const char *min_kver;
+	const char *max_kver;
 
 	const char *const *supported_archs;
 
diff --git a/lib/tst_test.c b/lib/tst_test.c
index 5e64fb5b63..c849401f33 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1083,6 +1083,40 @@ static bool check_min_kver(const char *min_kver, const int brk_nosupp)
 	return true;
 }
 
+/*
+ * Check for the maximal required kernel version.
+ *
+ * return: true if the kernel version is low enough, false otherwise.
+ */
+static bool check_max_kver(const char *max_kver, const int brk_nosupp)
+{
+	char *msg;
+	int dots, i, v1, v2, v3;
+
+	tst_parse_kver(max_kver, &v1, &v2, &v3);
+
+	for (i = 0, dots = 0; max_kver[i]; i++)
+		dots += (max_kver[i] == '.');
+
+	/*
+	 * For mainline kernel release without patch level (single dot e.g. "7.1")
+	 * ignore v3 (the sublevel): 7.1.x is always ok.
+	 * Do *not* ignore v3 on stable kernel release (2 dots, e.g. 7.1.5).
+	 */
+	if (tst_kvercmp(v1, v2, v3) > (dots == 1 ? 1023 : 0)) {
+		msg = "The test requires kernel %s or older";
+
+		if (brk_nosupp)
+			tst_brk(TCONF, msg, max_kver);
+		else
+			tst_res(TCONF, msg, max_kver);
+
+		return false;
+	}
+
+	return true;
+}
+
 /*
  * Checks if the struct results values are equal.
  *
@@ -1459,6 +1493,9 @@ static void do_setup(int argc, char *argv[])
 	if (tst_test->min_kver)
 		check_min_kver(tst_test->min_kver, 1);
 
+	if (tst_test->max_kver)
+		check_max_kver(tst_test->max_kver, 1);
+
 	if (tst_test->skip_in_lockdown && tst_lockdown_enabled() > 0)
 		tst_brk(TCONF, "Kernel is locked down, skipping test");
 
@@ -1582,6 +1619,9 @@ static void do_setup(int argc, char *argv[])
 			if (tst_test->filesystems && tst_test->filesystems->min_kver)
 				check_min_kver(tst_test->filesystems->min_kver, 1);
 
+			if (tst_test->filesystems && tst_test->filesystems->max_kver)
+				check_max_kver(tst_test->filesystems->max_kver, 1);
+
 			prepare_device(tst_test->filesystems);
 		}
 	}
@@ -1987,6 +2027,9 @@ static void run_tcase_on_fs(struct tst_fs *fs, const char *fs_type)
 	if (fs->min_kver && !check_min_kver(fs->min_kver, 0))
 		return;
 
+	if (fs->max_kver && !check_max_kver(fs->max_kver, 0))
+		return;
+
 	prepare_device(fs);
 
 	fork_testrun();
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 3/7] lib: Add support for max_kver to struct tst_test and tst_fs

[Andrea Cervesato via ltp]

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 4/7] creat07: Avoid timeout on the test failure

[Petr Vorel]

Test always needs to run kill() and waitpid() to avoid timeout.
This was not true when creat07_child.c unexpectedly succeeded (a test
failure).

Fixes: da3105af69 ("syscalls/creat07: Cleanup && Convert to new API")
Reported-by: linuxtestproject.agent@gmail.com
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
New in v4.

 testcases/kernel/syscalls/creat/creat07.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/creat/creat07.c b/testcases/kernel/syscalls/creat/creat07.c
index c7b85ee694..1de1b46621 100644
--- a/testcases/kernel/syscalls/creat/creat07.c
+++ b/testcases/kernel/syscalls/creat/creat07.c
@@ -35,7 +35,7 @@ static void verify_creat(void)
 
 	if (TST_RET != -1) {
 		tst_res(TFAIL, "creat() succeeded unexpectedly");
-		return;
+		goto kill;
 	}
 
 	if (TST_ERR == ETXTBSY)
@@ -43,6 +43,7 @@ static void verify_creat(void)
 	else
 		tst_res(TFAIL | TTERRNO, "creat() failed unexpectedly");
 
+kill:
 	SAFE_KILL(pid, SIGKILL);
 	SAFE_WAITPID(pid, NULL, 0);
 }
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 4/7] creat07: Avoid timeout on the test failure

[Andrea Cervesato via ltp]

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 5/7] creat07: execve04: Remove version check, add linux-git

[Petr Vorel]

Kernel commit 2a010c412853 ("fs: don't block i_writecount during exec")
from 6.11-rc1 was reverted in 3b832035387f ("Revert "fs: don't block
i_writecount during exec"") in v6.13-rc1 and backported into v6.11.11
and v6.12.2. Due LTP "no hide kernel bugs" policy remove kernel version
limitation and add missing linux-git tag.

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>
Reported-by: Cyril Hrubis <chrubis@suse.cz>
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
The same as in v4.

 testcases/kernel/syscalls/creat/creat07.c   | 20 ++++++++---------
 testcases/kernel/syscalls/execve/execve04.c | 24 ++++++++++-----------
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/testcases/kernel/syscalls/creat/creat07.c b/testcases/kernel/syscalls/creat/creat07.c
index 1de1b46621..92ff7d2682 100644
--- a/testcases/kernel/syscalls/creat/creat07.c
+++ b/testcases/kernel/syscalls/creat/creat07.c
@@ -6,6 +6,12 @@
 
 /*\
  * Check that :manpage:`creat(2)` sets ETXTBSY correctly.
+ *
+ * NOTE: write to executed file was allowed in 6.11-rc1:
+ * 2a010c412853 ("fs: don't block i_writecount during exec")
+ * but then reverted in v6.13-rc1:
+ * 3b832035387f ("Revert "fs: don't block i_writecount during exec""),
+ * backported into v6.11.11 and v6.12.2.
  */
 
 #include <sys/types.h>
@@ -48,20 +54,14 @@ kill:
 	SAFE_WAITPID(pid, NULL, 0);
 }
 
-static void setup(void)
-{
-	if ((tst_kvercmp(6, 11, 0)) >= 0) {
-		tst_brk(TCONF, "Skipping test, write to executed file is "
-			"allowed since 6.11-rc1.\n"
-			"2a010c412853 (\"fs: don't block i_writecount during exec\")");
-	}
-}
-
 static struct tst_test test = {
-	.setup = setup,
 	.test_all = verify_creat,
 	.needs_checkpoints = 1,
 	.forks_child = 1,
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "3b832035387ff508fdcf0fba66701afc78f79e3d"},
+		{}
+	},
 	.resource_files = (const char *const []) {
 		TEST_APP,
 		NULL
diff --git a/testcases/kernel/syscalls/execve/execve04.c b/testcases/kernel/syscalls/execve/execve04.c
index 35ec882a07..314710a32d 100644
--- a/testcases/kernel/syscalls/execve/execve04.c
+++ b/testcases/kernel/syscalls/execve/execve04.c
@@ -9,8 +9,14 @@
  */
 
 /*\
- * Attempt to :manpage:`execve(2)` a file which is being opened by another process for
- * writing fails with ETXTBSY.
+ * Attempt to :manpage:`execve(2)` a file which is being opened by another
+ * process for writing fails with ETXTBSY.
+ *
+ * NOTE: write to executed file was allowed in 6.11-rc1:
+ * 2a010c412853 ("fs: don't block i_writecount during exec")
+ * but then reverted in v6.13-rc1:
+ * 3b832035387f ("Revert "fs: don't block i_writecount during exec""),
+ * backported into v6.11.11 and v6.12.2.
  */
 
 #define _GNU_SOURCE
@@ -62,21 +68,15 @@ static void do_child(void)
 	exit(0);
 }
 
-static void setup(void)
-{
-	if ((tst_kvercmp(6, 11, 0)) >= 0) {
-		tst_brk(TCONF, "Skipping test, write to executed file is "
-			"allowed since 6.11-rc1.\n"
-			"2a010c412853 (\"fs: don't block i_writecount during exec\")");
-	}
-}
-
 static struct tst_test test = {
-	.setup = setup,
 	.test_all = verify_execve,
 	.forks_child = 1,
 	.child_needs_reinit = 1,
 	.needs_checkpoints = 1,
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "3b832035387ff508fdcf0fba66701afc78f79e3d"},
+		{}
+	},
 	.resource_files = (const char *const []) {
 		TEST_APP,
 		NULL
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 6/7] fanotify20: Skip on v7.2

[Petr Vorel]

fanotify_init() used to reject FAN_REPORT_PIDFD combined with
FAN_REPORT_TID with EINVAL. Since Linux v7.2, fanotify supports
reporting pidfds for thread IDs, so this combination is expected to
succeed.

The test that these flag combinations are allowed:
                FLAGS_DESC(FAN_REPORT_PIDFD | FAN_REPORT_TID),
		FLAGS_DESC(FAN_REPORT_PIDFD | FAN_REPORT_FID |
			   FAN_REPORT_DFID_NAME),

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.

Reported-by: AnonymeMeow <anonymemeow@gmail.com>
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
The same as in v4.

 testcases/kernel/syscalls/fanotify/fanotify20.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/testcases/kernel/syscalls/fanotify/fanotify20.c b/testcases/kernel/syscalls/fanotify/fanotify20.c
index b32ecf6aa3..db4a5ba63b 100644
--- a/testcases/kernel/syscalls/fanotify/fanotify20.c
+++ b/testcases/kernel/syscalls/fanotify/fanotify20.c
@@ -15,6 +15,9 @@
  *
  * NOTE: FAN_REPORT_PIDFD support was added in v5.15-rc1 in
  * af579beb666a ("fanotify: add pidfd support to the fanotify API").
+ *
+ * NOTE: since v7.2, fanotify supports reporting pidfds for thread IDs => skip
+ * the test.
  */
 
 #define _GNU_SOURCE
@@ -75,6 +78,7 @@ static void do_cleanup(void)
 
 static struct tst_test test = {
 	.setup = do_setup,
+	.max_kver = "7.1",
 	.test = do_test,
 	.tcnt = ARRAY_SIZE(test_cases),
 	.cleanup = do_cleanup,
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v5 7/7] lib: Add 2 basic tests for .min_kver && .max_kver

[Petr Vorel]

* tst_max_kver_old.c
Basic test to test .max_kver detection works. Test should TCONF due
running on newer kernel.

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

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Changes v4->v5:
* Add one more test, increase max_kver in the test added previous
  version.

 lib/newlib_tests/.gitignore              |  2 ++
 lib/newlib_tests/runtest.sh              |  2 ++
 lib/newlib_tests/tst_max_kver_old.c      | 21 +++++++++++++++++++++
 lib/newlib_tests/tst_min_kver_max_kver.c | 22 ++++++++++++++++++++++
 4 files changed, 47 insertions(+)
 create mode 100644 lib/newlib_tests/tst_max_kver_old.c
 create mode 100644 lib/newlib_tests/tst_min_kver_max_kver.c

diff --git a/lib/newlib_tests/.gitignore b/lib/newlib_tests/.gitignore
index b851638246..d55e38bb29 100644
--- a/lib/newlib_tests/.gitignore
+++ b/lib/newlib_tests/.gitignore
@@ -72,3 +72,5 @@ test_brk_pass
 test_brk_variant
 test_fail_variant
 test_cpu_vendor
+tst_max_kver_old
+tst_min_kver_max_kver
diff --git a/lib/newlib_tests/runtest.sh b/lib/newlib_tests/runtest.sh
index 71808ef8b8..ad38d845a3 100755
--- a/lib/newlib_tests/runtest.sh
+++ b/lib/newlib_tests/runtest.sh
@@ -26,6 +26,8 @@ tst_device
 tst_expiration_timer
 tst_filesystems01
 tst_fuzzy_sync0[1-3]
+tst_max_kver_old
+tst_min_kver_max_kver
 tst_needs_cmds0[1-36-8]
 tst_res_hexd
 tst_safe_sscanf
diff --git a/lib/newlib_tests/tst_max_kver_old.c b/lib/newlib_tests/tst_max_kver_old.c
new file mode 100644
index 0000000000..3b03f555b6
--- /dev/null
+++ b/lib/newlib_tests/tst_max_kver_old.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2026 Petr Vorel <pvorel@suse.cz>
+ */
+
+/*
+ * Basic test to test .max_kver detection works.
+ * Test should TCONF due running on newer kernel.
+ */
+
+#include "tst_test.h"
+
+static void do_test(void)
+{
+	tst_res(TFAIL, "Really running on kernel 1.0?");
+}
+
+static struct tst_test test = {
+	.max_kver = "1.0",
+	.test_all = do_test,
+};
diff --git a/lib/newlib_tests/tst_min_kver_max_kver.c b/lib/newlib_tests/tst_min_kver_max_kver.c
new file mode 100644
index 0000000000..5c1b0b3a29
--- /dev/null
+++ b/lib/newlib_tests/tst_min_kver_max_kver.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2026 Petr Vorel <pvorel@suse.cz>
+ */
+
+/*
+ * Basic test to test that .min_kver and .max_kver can be used together.
+ * Test should TCONF or TPASS.
+ */
+
+#include "tst_test.h"
+
+static void do_test(void)
+{
+	tst_res(TPASS, "Test has sufficient kernel version");
+}
+
+static struct tst_test test = {
+	.min_kver = "4.4",
+	.max_kver = "7.2",
+	.test_all = do_test,
+};
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 7/7] lib: Add 2 basic tests for .min_kver && .max_kver

[Andrea Cervesato via ltp]

Hi Petr,

> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2026 Petr Vorel <pvorel@suse.cz>
> + */
> +
> +/*
> + * Basic test to test that .min_kver and .max_kver can be used together.
> + * Test should TCONF or TPASS.
> + */
> +
> +#include "tst_test.h"
> +
> +static void do_test(void)
> +{
> +	tst_res(TPASS, "Test has sufficient kernel version");
> +}
> +
> +static struct tst_test test = {
> +	.min_kver = "4.4",
> +	.max_kver = "7.2",
> +	.test_all = do_test,
> +};

this test is a bit weird, it's system dependent and it will TPASS or
TCONF according to the kernel version. Is there a way to test this
in a different way? I know it's hacky, but maybe we can use
__attribute__((constructor)) and fetch uname() info before running
the maximum kernel version check.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 7/7] lib: Add 2 basic tests for .min_kver && .max_kver

[Petr Vorel]

Hi Andrea,

> Hi Petr,

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

> this test is a bit weird, it's system dependent and it will TPASS or
> TCONF according to the kernel version. Is there a way to test this
> in a different way? I know it's hacky, but maybe we can use
> __attribute__((constructor)) and fetch uname() info before running
> the maximum kernel version check.

Although this is an interesting idea, I'm not sure if I find time for it. Feel
free to further improve it. For me is in the end trying to fix fanotify20 :).

The point of the test is to at least run something (kind of minimal testing but
better than nothing, because it's naive to expect anybody who touches library
tests it carefully with the real tests).

Anyway, in CI it will be always the same due using container (TPASS on Ubuntu's
6.17.0-1020-azure).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 7/7] lib: Add 2 basic tests for .min_kver && .max_kver

[Andrea Cervesato via ltp]

> Although this is an interesting idea, I'm not sure if I find time for it. Feel
> free to further improve it. For me is in the end trying to fix fanotify20 :).

ok feel free to merge for now.

Andrea
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 7/7] lib: Add 2 basic tests for .min_kver && .max_kver

[Avinesh Kumar via ltp]

Hi Petr,

Reviewed-by: Avinesh Kumar <avinesh.kumar@suse.com>
for whole series.

Thanks,
Avinesh


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v5 0/7] Add support for .max_kver

[Li Wang]

> Petr Vorel (7):

>   tst_kvercmp: Factor out error handling
>   lib: Rename function check_kver() => check_min_kver()
>   lib: Add support for max_kver to struct tst_test and tst_fs
>   creat07: Avoid timeout on the test failure
>   creat07: execve04: Remove version check, add linux-git
>   fanotify20: Skip on v7.2
>   lib: Add 2 basic tests for .min_kver && .max_kver

For the whole patchset:

Reviewed-by: Li Wang <li.wang@linux.dev>

-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v4 1/9] tst_kvercmp: Factor out error handling

[Petr Vorel]

Error check was already on 2 places (and possibly more will be added in
the future).

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
New in v4.

 lib/tst_kvercmp.c | 23 +++++++++++++++++------
 lib/tst_test.c    |  6 +-----
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/lib/tst_kvercmp.c b/lib/tst_kvercmp.c
index 9e1a511aff..c0714073d4 100644
--- a/lib/tst_kvercmp.c
+++ b/lib/tst_kvercmp.c
@@ -45,7 +45,7 @@ static char *parse_digit(const char *str, int *d)
 	return end;
 }
 
-int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
+static int _tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
 {
 	const char *str = str_kver;
 
@@ -81,17 +81,28 @@ int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
 	return 0;
 }
 
-int tst_kvcmp(const char *cur_kver, int r1, int r2, int r3)
+int tst_parse_kver(const char *str_kver, int *v1, int *v2, int *v3)
 {
-	int a1, a2, a3;
-	int testver, currver;
+	int rc;
+
+	rc = _tst_parse_kver(str_kver, v1, v2, v3);
 
-	if (tst_parse_kver(cur_kver, &a1, &a2, &a3)) {
+	if (rc) {
 		tst_resm(TWARN,
 			 "Invalid kernel version %s, expected %%d.%%d.%%d",
-		         cur_kver);
+		         str_kver);
 	}
 
+	return rc;
+}
+
+int tst_kvcmp(const char *cur_kver, int r1, int r2, int r3)
+{
+	int a1, a2, a3;
+	int testver, currver;
+
+	tst_parse_kver(cur_kver, &a1, &a2, &a3);
+
 	testver = (r1 << 20) + (r2 << 10) + r3;
 	currver = (a1 << 20) + (a2 << 10) + a3;
 
diff --git a/lib/tst_test.c b/lib/tst_test.c
index 5c3607016e..351b155700 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1067,11 +1067,7 @@ static bool check_kver(const char *min_kver, const int brk_nosupp)
 	char *msg;
 	int v1, v2, v3;
 
-	if (tst_parse_kver(min_kver, &v1, &v2, &v3)) {
-		tst_res(TWARN,
-			"Invalid kernel version %s, expected %%d.%%d.%%d",
-			min_kver);
-	}
+	tst_parse_kver(min_kver, &v1, &v2, &v3);
 
 	if (tst_kvercmp(v1, v2, v3) < 0) {
 		msg = "The test requires kernel %s or newer";
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent]

Hi Petr,

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

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

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

Could this explain the distinction between minimum- and maximum-version
checks without referring to the next patch? Commit messages in a series
should be self-contained.

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

> +	.max_kver = "7.1",

Could only the FAN_REPORT_PIDFD | FAN_REPORT_TID case be adjusted or split
instead? This skips every case on Linux 7.2 and newer, including
FAN_REPORT_PIDFD | FAN_REPORT_FID | FAN_REPORT_DFID_NAME, whose expected
behavior did not change. That permanently removes its regression coverage on
newer kernels.

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

> +	.min_kver = "4.4",
> +	.max_kver = "5.0",

How does this exercise the successful min/max path on current kernels? It
exits with TCONF on every kernel newer than 5.0, and runtest.sh accepts TCONF
as success without calling do_test(). Could the upper bound be made safely
higher than the running kernel, or otherwise deterministic?

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

> +/**
> + * tst_kver_cmp() - Compare two kernel versions, versions passed by 3 integers.
> + *
> + * @a1: First kernel major version.
> + * @a2: First kernel minor version.
> + * @a3: First kernel patch level.
> + * @b1: Second kernel major version.
> + * @b2: Second kernel minor  version.
> + * @b3: Second kernel patch level.
> + */

Could this document the return value? Callers need to know that a negative
result means the first version is older, zero means equal, and a positive
result means newer.

> This will be heavily used in metaparse.c (speedup of metadata
> generation) in the next commit.

Could the reusable comparison need be explained without referring to the next
patch? Commit messages in a series should be self-contained.

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

> Will be used for metadata.c in the next commit.

Could this describe the host-tool link or build-order problem solved by the
rule? The current body relies on the next patch and does not explain why host
targets need MAKE_DEPS.

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

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

Could this apply the same two-component max_kver semantics as
check_max_kver()? For example, min_kver "7.1.5" and max_kver "7.1" is rejected
as 7.1.5 > 7.1.0, although the API defines max_kver "7.1" to include every
7.1.x kernel.

> +include $(top_srcdir)/include/mk/testcases.mk
>
> +metaparse: HOST_CFLAGS		+= -I$(abs_srcdir)/../include -L$(abs_builddir)/../lib
> +metaparse: HOST_LDLIBS		+= -lltp

How will this work for cross builds? metaparse is built with HOSTCC, while
testcases.mk builds libltp.a with the target CC. A host linker cannot consume
a target-architecture archive. Could the parsing and comparison code used by
metaparse be built with HOSTCC or shared without linking the target library?

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

Re: [LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent]

Hi Petr,

On Wed, Aug 5, 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 or
tst_parse_kver_internal? Identifiers beginning with an underscore are
reserved at file scope by C, and LTP's C rules explicitly prohibit them.

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

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

How can this self-test verify that a valid range is run? On kernel 7.2,
the framework exits with TCONF before do_test() is called, and runtest.sh
accepts TCONF as success. The test therefore remains green even if running
a test inside a valid min/max range is broken. Could the test use a range
containing the running kernel, or assert the gating result another way?

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

> +/**
> + * tst_kver_cmp() - Compare two kernel versions, versions passed by 3 integers.
> + *
> + * @a1: First kernel major version.
> + * @a2: First kernel minor version.
> + * @a3: First kernel patch level.
> + * @b1: Second kernel major version.
> + * @b2: Second kernel minor  version.
> + * @b3: Second kernel patch level.
> + */

Could this public API document its return value with the required kernel-doc
Return: section? It should describe the negative, zero, and positive cases.

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

> +metaparse: HOST_CFLAGS		+= -I$(abs_srcdir)/../include -L$(abs_builddir)/../lib
> +metaparse: HOST_LDLIBS		+= -lltp

How does this work for cross builds? metaparse is linked with HOSTCC, while
lib/libltp.a is built with the target CC. HOSTCC cannot link
target-architecture objects, so metadata generation fails with an
incompatible object format. Could the needed parsing and comparison code be
built with HOSTCC and kept free of target-library dependencies instead?

> +	if (min_kver && max_kver) {
> +		if (tst_kver_cmp(a1, a2, a3, b1, b2, b3) < 0) {
> +			fprintf(stderr, "%s: min_kver (%s) > max_kver (%s)\n",

Could this comparison apply the documented two-component max_kver semantics?
For example, min_kver "7.1.5" and max_kver "7.1" is a valid nonempty range
because max_kver "7.1" includes every 7.1.x stable release. This literal
comparison treats the maximum as 7.1.0 and rejects that range.

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

Re: [LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent]

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

Re: [LTP] tst_kvercmp: Factor out error handling

[linuxtestproject.agent]

Hi Petr,

On Aug 5, 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 be renamed to parse_kver? File-scope identifiers beginning with an
underscore are reserved by C, and LTP's coding rules prohibit such names.

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

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

Could the motivation be stated without referring to the next patch? Each
commit message should stand on its own rather than depend on series position.

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

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

Could this path kill and reap pid before returning? Removing the version gate
makes it reachable on affected 6.11 and 6.12 kernels, but the child remains
paused indefinitely. The framework then blocks in tst_reap_children() until
the watchdog terminates the test instead of returning the intended TFAIL.

> 	TEST(execve(TEST_APP, argv, environ));

How is the writer child released when execve() succeeds on an affected
kernel? The test process is replaced by execve_child, which reports TFAIL and
exits, while the writer remains blocked in TST_CHECKPOINT_WAKE_AND_WAIT(0) and
becomes an orphan.

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

> 	.max_kver = "7.1",

Could the test keep running and only adjust the expected result of
FAN_REPORT_PIDFD | FAN_REPORT_TID on kernels supporting thread pidfds? This
test-wide limit also removes the
FAN_REPORT_PIDFD | FAN_REPORT_FID | FAN_REPORT_DFID_NAME case on 7.2 and all
newer kernels, and that exact combination is not tested elsewhere in LTP.

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

> 	.min_kver = "4.4",
> 	.max_kver = "5.0",

How can this exercise do_test() on current CI kernels? The current kernel must
lie between the bounds; min_kver being less than max_kver is not sufficient.
With this maximum, including on stable 7.2, the self-test only reports TCONF
and never tests the new success path.

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

> int tst_kver_cmp(int a1, int a2, int a3, int b1, int b2, int b3);

Could the new public function's kernel-doc include a Return: section
describing the comparison result?

> This will be heavily used in metaparse.c (speedup of metadata
> generation) in the next commit.

Could this motivation be stated without referring to the next patch? Each
commit message should stand on its own.

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

> Will be used for metadata.c in the next commit.

Could the commit message instead explain why host targets need access to
MAKE_DEPS without depending on a later patch?

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

> metaparse: HOST_LDLIBS		+= -lltp

How can this work for a cross-compilation? metaparse is built with HOSTCC, but
-lltp resolves to lib/libltp.a built with the target CC, so the host linker
cannot consume the archive. Could the version helper be compiled with HOSTCC,
or moved into an architecture-independent host library?

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

Re: [LTP] tst_kvercmp: Factor out error handling

[Petr Vorel]

Hi all,

> Hi Petr,

> On Aug 5, 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 be renamed to parse_kver? File-scope identifiers beginning with an
> underscore are reserved by C, and LTP's coding rules prohibit such names.

I thought this is wrong, because we have functions with underscore, but it's
trailing underscore, not the leading one.

=> I'll rename to tst_parse_kver_().

Also, agent does not know about LTP rule to have functions in lib with leading
tst_.

> --- [PATCH 2/9] ---

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

> Could the motivation be stated without referring to the next patch? Each
> commit message should stand on its own rather than depend on series position.

Well, we try to split code into commits to be easily revieweable. With that
sometimes is hard to avoid referring to commits. Preparation for other changes
separated into it's own commit helps is an explanation itself.

=> Consider as irrelevant.

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

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

> Could this path kill and reap pid before returning? Removing the version gate
> makes it reachable on affected 6.11 and 6.12 kernels, but the child remains
> paused indefinitely. The framework then blocks in tst_reap_children() until
> the watchdog terminates the test instead of returning the intended TFAIL.

=> Indeed, this is bug for creat07.c, at least on SLE16 kernel which is based on 6.12,
where test hangs until timeouts on:

creat07.c:43: TFAIL: creat() succeeded unexpectedly

I guess I'll simply use goto to do the needed cleanup:

+++ testcases/kernel/syscalls/creat/creat07.c
@@ -41,7 +41,7 @@ static void verify_creat(void)

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

        if (TST_ERR == ETXTBSY)
@@ -49,6 +49,7 @@ static void verify_creat(void)
        else
                tst_res(TFAIL | TTERRNO, "creat() failed unexpectedly");

+kill:
        SAFE_KILL(pid, SIGKILL);
        SAFE_WAITPID(pid, NULL, 0);
 }
---

execve04.c simply fails on that kernel which is IMHO correct (not hiding bugs):
execve_child.c:27: TFAIL: execve_child shouldn't be executed

> > 	TEST(execve(TEST_APP, argv, environ));

> How is the writer child released when execve() succeeds on an affected
> kernel? The test process is replaced by execve_child, which reports TFAIL and
> exits, while the writer remains blocked in TST_CHECKPOINT_WAKE_AND_WAIT(0) and
> becomes an orphan.

I hope the above patch fixes that. Shouldn't be this fixed separately
(regardless on a removed .min_kver), it can be problematic on any kernel
version.

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

> > 	.max_kver = "7.1",

> Could the test keep running and only adjust the expected result of
> FAN_REPORT_PIDFD | FAN_REPORT_TID on kernels supporting thread pidfds? This
> test-wide limit also removes the
> FAN_REPORT_PIDFD | FAN_REPORT_FID | FAN_REPORT_DFID_NAME case on 7.2 and all
> newer kernels, and that exact combination is not tested elsewhere in LTP.

No, we agreed, this is ok (I'm explaining this second time and I suppose I will
have to do it on all patchset versions I'll send).

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

> > 	.min_kver = "4.4",
> > 	.max_kver = "5.0",

> How can this exercise do_test() on current CI kernels? The current kernel must
> lie between the bounds; min_kver being less than max_kver is not sufficient.
> With this maximum, including on stable 7.2, the self-test only reports TCONF
> and never tests the new success path.

I deliberately wanted to get TCONF on the current kernel, i.e. the fact than
using both will result in TCONF not in TBROK. Also, it does not matter if the
test TCONF due old version or run and then TPASS, it's about testing library
setup() run with .min_kver and .max_kver (test itself does nothing). Also any
kernel version will sooner later be old and thus TCONF, why not to do it now?
Not it's also a test that any old version will just TCONF not TBROK. I try to
document it better in the test.

> --- [PATCH 7/9] ---

> > int tst_kver_cmp(int a1, int a2, int a3, int b1, int b2, int b3);

> Could the new public function's kernel-doc include a Return: section
> describing the comparison result?

Commit will be removed in the next version.

> > This will be heavily used in metaparse.c (speedup of metadata
> > generation) in the next commit.

> Could this motivation be stated without referring to the next patch? Each
> commit message should stand on its own.

> --- [PATCH 8/9] ---

> > Will be used for metadata.c in the next commit.

> Could the commit message instead explain why host targets need access to
> MAKE_DEPS without depending on a later patch?

Commit will be removed in the next version.

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

> > metaparse: HOST_LDLIBS		+= -lltp

> How can this work for a cross-compilation? metaparse is built with HOSTCC, but
> -lltp resolves to lib/libltp.a built with the target CC, so the host linker
> cannot consume the archive. Could the version helper be compiled with HOSTCC,
> or moved into an architecture-independent host library?

Commit will be removed in the next version.

> 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