[LTP] [PATCH v3 0/5] Add support for .max_kver

[LTP] [PATCH v3 0/5] Add support for .max_kver

[Petr Vorel]

Changes v2->v3:
* Allow to pass mainline release (e.g. max_version = "7.1") on any stable
  release (e.g. 7.1.5). Stable releases (e.g. 7.1.5) are compared as
  expected. For this I'd like an explicit ack.

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

Changes v1->v2:
* Fixed version 6.11 => 6.10 (execve04, creat07)
* Fixed version 7.2 => 7.1 (fanotify20)

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 (5):
  lib: Rename function check_kver() => check_min_kver()
  lib: Add support for max_kver to struct tst_test and tst_fs
  execve04: Use .max_kver
  creat07: Use .max_kver
  fanotify20: Skip on v7.2

 include/tst_test.h                            | 13 ++++-
 lib/tst_test.c                                | 57 +++++++++++++++++--
 testcases/kernel/syscalls/creat/creat07.c     | 14 ++---
 testcases/kernel/syscalls/execve/execve04.c   | 14 ++---
 .../kernel/syscalls/fanotify/fanotify20.c     |  4 ++
 5 files changed, 76 insertions(+), 26 deletions(-)

-- 
2.55.0


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

[LTP] [PATCH v3 1/5] lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

Preparation for a 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 v2.

 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 5c3607016e..778a1fed40 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;
@@ -1461,7 +1461,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");
@@ -1584,7 +1584,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);
 		}
@@ -1988,7 +1988,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

Re: [LTP] lib: Rename function check_kver() => check_min_kver()

[linuxtestproject.agent]

Hi Petr,

On Fri, 31 Jul 2026, Petr Vorel wrote:
> lib: Rename function check_kver() => check_min_kver()

--- [PATCH 1/5] ---

> Preparation for a next commit.

Could the message explain that the rename distinguishes the minimum-version
helper from the new maximum-version helper, without referring to a later
patch? The current body does not explain the change independently.

--- [PATCH 2/5] ---

> + * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
> + * 7.1.5). Stable releases are compared as expected.

Could this example use ``max_kver``? As written, the new field documents the
opposite API.

> +	for (i=0, dots=0; max_kver[i]; i++)

Could spaces be added around both assignment operators to follow kernel
coding style?

--- [PATCH 3/5] ---

> +	.max_kver = "6.10",

Could this test be allowed to run again on Linux 7.2? In that tree,
do_open_execat() calls exe_file_deny_write_access() and returns ETXTBSY when
the executable is open for writing (fs/exec.c:800-802).

A permanent maximum version therefore reports TCONF for behavior that is
valid again. It cannot represent the temporary 6.11 through 7.1 behavior
window.

--- [PATCH 4/5] ---

> +	.max_kver = "6.10",

Could creat07 also be allowed to run again on Linux 7.2? The exec path makes
i_writecount negative through exe_file_deny_write_access(), and creat() then
reaches get_write_access(), which returns ETXTBSY for a negative count
(include/linux/fs.h:2813-2816).

This maximum bound suppresses valid 7.2 coverage and cannot describe the
temporary 6.11 through 7.1 behavior window.

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

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

Could this claim be corrected? Other tests exercise FAN_REPORT_TID and
FAN_REPORT_PIDFD separately, but fanotify20 is the only LTP test combining
them.

> +	.max_kver = "7.1",

Could the first case instead expect success when thread pidfds are supported,
while retaining the second valid-combination check? Linux 7.2 now uses
task_pid(current) for FAN_REPORT_TID and creates a thread pidfd
(fs/notify/fanotify/fanotify.c:843-849 and
fs/notify/fanotify/fanotify_user.c:906-913). Skipping the whole test removes
the only coverage of the newly valid combination.

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] lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

Hi all,

> Hi Petr,

> On Fri, 31 Jul 2026, Petr Vorel wrote:
> > lib: Rename function check_kver() => check_min_kver()

> --- [PATCH 1/5] ---

> > Preparation for a next commit.

> Could the message explain that the rename distinguishes the minimum-version
> helper from the new maximum-version helper, without referring to a later
> patch? The current body does not explain the change independently.

Hm, I'm not sure if that's needed

> --- [PATCH 2/5] ---

> > + * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
> > + * 7.1.5). Stable releases are compared as expected.

> Could this example use ``max_kver``? As written, the new field documents the
> opposite API.

Ah, thanks! Before merge I'll amend:

- * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
+ * on any stable release (test with ``max_kver = "7.1"`` runs also on kernel

> > +	for (i=0, dots=0; max_kver[i]; i++)

> Could spaces be added around both assignment operators to follow kernel
> coding style?

Ah, thanks! Before merge I'll amend:

-	for (i=0, dots=0; max_kver[i]; i++)
+	for (i = 0, dots = 0; max_kver[i]; i++)

> --- [PATCH 3/5] ---

> > +	.max_kver = "6.10",

> Could this test be allowed to run again on Linux 7.2? In that tree,
> do_open_execat() calls exe_file_deny_write_access() and returns ETXTBSY when
> the executable is open for writing (fs/exec.c:800-802).

> A permanent maximum version therefore reports TCONF for behavior that is
> valid again. It cannot represent the temporary 6.11 through 7.1 behavior
> window.

@Cyril @Andrea could you also please double check?

> --- [PATCH 4/5] ---

> > +	.max_kver = "6.10",

> Could creat07 also be allowed to run again on Linux 7.2? The exec path makes
> i_writecount negative through exe_file_deny_write_access(), and creat() then
> reaches get_write_access(), which returns ETXTBSY for a negative count
> (include/linux/fs.h:2813-2816).

> This maximum bound suppresses valid 7.2 coverage and cannot describe the
> temporary 6.11 through 7.1 behavior window.

@Cyril @Andrea could you also please double check?

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

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

> Could this claim be corrected? Other tests exercise FAN_REPORT_TID and
> FAN_REPORT_PIDFD separately, but fanotify20 is the only LTP test combining
> them.

Hm, do we care when Amir is ok with it?

Kind regards,
Petr

> > +	.max_kver = "7.1",

> Could the first case instead expect success when thread pidfds are supported,
> while retaining the second valid-combination check? Linux 7.2 now uses
> task_pid(current) for FAN_REPORT_TID and creates a thread pidfd
> (fs/notify/fanotify/fanotify.c:843-849 and
> fs/notify/fanotify/fanotify_user.c:906-913). Skipping the whole test removes
> the only coverage of the newly valid combination.

> 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] lib: Rename function check_kver() => check_min_kver()

[Andrea Cervesato via ltp]

Hi Petr,

> @Cyril @Andrea could you also please double check?

It's correct.

The legacy ETXTBSY behavior was fully restored in commit
3b832035387f (Revert "fs: don't block i_writecount during exec").

So we have a window where this is not valid anymore and we should
take this in consideration inside the test.

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

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

Re: [LTP] lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

Hi Andrea,

> Hi Petr,

> > @Cyril @Andrea could you also please double check?

> It's correct.

> The legacy ETXTBSY behavior was fully restored in commit
> 3b832035387f (Revert "fs: don't block i_writecount during exec").

Thanks!

> So we have a window where this is not valid anymore and we should
> take this in consideration inside the test.

In that case we want to have both in a single commit, right?
=> yet another version.

Kind regards,
Petr

> Regards,

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

Re: [LTP] lib: Rename function check_kver() => check_min_kver()

[Andrea Cervesato via ltp]

> In that case we want to have both in a single commit, right?
> => yet another version.

Yes, I think so

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

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

[LTP] [RFC] Re: lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

Hi all,

> > In that case we want to have both in a single commit, right?
> > => yet another version.

> Yes, I think so

I'm not sure what's reasonable, therefore RFC please.

We can for sure can have test with both flags, .min_kver < .max_kver:

.min_kver = "6.5"
.max_kver = "7.2"

which will be tested on kernels <6.5, 7.2> (including all their stable
versions). Here the code works like (using AND):

$(uname -r) >= .min_kver && $(uname -r) <= .max_kver

(BTW although current version prints only the version which is not sufficient.
And I think it's better than print the range without specifying which version is
not sufficient).

But can we have also a variant when .min_kver > .max_kver (using OR)?

.max_kver = "6.10"
.min_kver = "7.2"

i.e it will be tested on <whatever_minimum_LTP is, 6.10> <7.2, future versions>:

$(uname -r) <= .max_kver || $(uname -r) >= .min_kver

Advantages:
* only 2 flags
* no need to parse complicated expressions (e.g. "< 6.9, > 7.1" or "le 6.10, ge 7.2")

Disadvantages
* a bit unintuitive
* complicated expressions will not work

WDYT?

Kind regards,
Petr

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

Re: [LTP] lib: Rename function check_kver() => check_min_kver()

[Cyril Hrubis]

Hi!
> > @Cyril @Andrea could you also please double check?
> 
> It's correct.
> 
> The legacy ETXTBSY behavior was fully restored in commit
> 3b832035387f (Revert "fs: don't block i_writecount during exec").

Isn't this a case where we should just fail if the revert wasn't
backported?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] lib: Rename function check_kver() => check_min_kver()

[Petr Vorel]

Hi all,

> Hi!
> > > @Cyril @Andrea could you also please double check?

> > It's correct.

> > The legacy ETXTBSY behavior was fully restored in commit
> > 3b832035387f (Revert "fs: don't block i_writecount during exec").

> Isn't this a case where we should just fail if the revert wasn't
> backported?

Probably yes. Also 3b832035387f is from 6.13. And I see it backported at least
on 6.12.2 as 13111945c242 [1].

BTW AI asked for enabling it on 7.2, I'm not sure why.

Anyway, we might not need the case > .max_kver || < .min_kver now, but it might
be needed later. But I'd not implement it until really needed.

Kind regards,
Petr

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.101&id=13111945c2420c2e352867ec96bb70c13ef37df9

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

[LTP] [PATCH v3 2/5] 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>
---
Changes v2->v3:
* Allow to pass mainline release (e.g. max_version = "7.1") on any stable
  release (e.g. 7.1.5). Stable releases (e.g. 7.1.5) are compared as
  expected. For this I'd like an explicit ack.

 include/tst_test.h | 13 ++++++++++++-
 lib/tst_test.c     | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/include/tst_test.h b/include/tst_test.h
index c69362485e..318b2f79b7 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 ``min_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 778a1fed40..8b9abe716a 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1087,6 +1087,44 @@ 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;
+
+	if (tst_parse_kver(max_kver, &v1, &v2, &v3)) {
+		tst_res(TWARN,
+			"Invalid kernel version %s, expected %%d.%%d.%%d",
+			max_kver);
+	}
+
+	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.
  *
@@ -1463,6 +1501,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");
 
@@ -1586,6 +1627,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);
 		}
 	}
@@ -1991,6 +2035,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 v3 2/5] lib: Add support for max_kver to struct tst_test and tst_fs

[Avinesh Kumar via ltp]

On 7/31/26 12:51 PM, Petr Vorel wrote:
> 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>
> ---
> Changes v2->v3:
> * Allow to pass mainline release (e.g. max_version = "7.1") on any stable
>    release (e.g. 7.1.5). Stable releases (e.g. 7.1.5) are compared as
>    expected. For this I'd like an explicit ack.
> 
>   include/tst_test.h | 13 ++++++++++++-
>   lib/tst_test.c     | 47 ++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/include/tst_test.h b/include/tst_test.h
> index c69362485e..318b2f79b7 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 ``min_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 778a1fed40..8b9abe716a 100644
> --- a/lib/tst_test.c
> +++ b/lib/tst_test.c
> @@ -1087,6 +1087,44 @@ 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;
> +
> +	if (tst_parse_kver(max_kver, &v1, &v2, &v3)) {
> +		tst_res(TWARN,
> +			"Invalid kernel version %s, expected %%d.%%d.%%d",
> +			max_kver);
> +	}
> +
> +	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;
> +}

Hi Petr,
This looks good. I tested it (and other patches) as well.

on my system, test runs fine -
tst_test.c:2097: TINFO: Tested kernel: 7.1.4-1-default
...

and
on >=7.2

# ./fanotify20
tst_test.c:1118: TCONF: The test requires kernel 7.1 or older


so feel free to add
Tested-by: Avinesh Kumar <avinesh.kumar@suse.com>
Reviewed-by: Avinesh Kumar <avinesh.kumar@suse.com>

for whole series.

Thanks,
Avinesh



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

[LTP] [PATCH v3 3/5] execve04: Use .max_kver

[Petr Vorel]

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

 testcases/kernel/syscalls/execve/execve04.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/testcases/kernel/syscalls/execve/execve04.c b/testcases/kernel/syscalls/execve/execve04.c
index 35ec882a07..6f06a4a4cc 100644
--- a/testcases/kernel/syscalls/execve/execve04.c
+++ b/testcases/kernel/syscalls/execve/execve04.c
@@ -11,6 +11,9 @@
 /*\
  * Attempt to :manpage:`execve(2)` a file which is being opened by another process for
  * writing fails with ETXTBSY.
+ *
+ * NOTE: write to executed file is allowed since 6.11-rc1:
+ * 2a010c412853 ("fs: don't block i_writecount during exec")
  */
 
 #define _GNU_SOURCE
@@ -62,19 +65,10 @@ 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,
+	.max_kver = "6.10",
 	.child_needs_reinit = 1,
 	.needs_checkpoints = 1,
 	.resource_files = (const char *const []) {
-- 
2.55.0


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

[LTP] [PATCH v3 4/5] creat07: Use .max_kver

[Petr Vorel]

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

 testcases/kernel/syscalls/creat/creat07.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/testcases/kernel/syscalls/creat/creat07.c b/testcases/kernel/syscalls/creat/creat07.c
index c7b85ee694..2b15d79b47 100644
--- a/testcases/kernel/syscalls/creat/creat07.c
+++ b/testcases/kernel/syscalls/creat/creat07.c
@@ -6,6 +6,9 @@
 
 /*\
  * Check that :manpage:`creat(2)` sets ETXTBSY correctly.
+ *
+ * NOTE: write to executed file is allowed since 6.11-rc1:
+ * 2a010c412853 ("fs: don't block i_writecount during exec")
  */
 
 #include <sys/types.h>
@@ -47,19 +50,10 @@ static void verify_creat(void)
 	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,
+	.max_kver = "6.10",
 	.forks_child = 1,
 	.resource_files = (const char *const []) {
 		TEST_APP,
-- 
2.55.0


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

[LTP] [PATCH v3 5/5] 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 v2.

 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