* Re: [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error
2024-09-25 8:49 [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error Xiao Yang
@ 2024-09-26 11:18 ` Cyril Hrubis
2024-11-04 16:38 ` Petr Vorel
2024-11-04 16:45 ` Petr Vorel
` (2 subsequent siblings)
3 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2024-09-26 11:18 UTC (permalink / raw)
To: Xiao Yang; +Cc: ltp
Hi!
> If the value of max_user_namespaces is set to 10 but more than
> 10 user namspaces are currently used on system. In this case,
> these tests fail with ENOSPC. for example:
>
> # lsns -t user -n | wc -l
> 17
>
> # ./fanotify17
> ...
> fanotify17.c:174: TINFO: Test #0: Global groups limit in init user ns
> fanotify17.c:130: TPASS: Created 128 groups - below groups limit (128)
> fanotify17.c:174: TINFO: Test #1: Global groups limit in privileged user ns
> fanotify17.c:154: TFAIL: unshare(CLONE_NEWUSER) failed: ENOSPC (28)
> tst_test.c:452: TBROK: Invalid child (6958) exit value 1
That's strange the test seems to work for me even if it's over the
limit.
$ lsns -t user -n | wc -l
14
I suppose that since the test is executed as a root since it has
.require_root the limits does not apply. It's strange that they apply in
your case. Which kernel is this?
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error
2024-09-26 11:18 ` Cyril Hrubis
@ 2024-11-04 16:38 ` Petr Vorel
0 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2024-11-04 16:38 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: ltp
Hi Cyril, Xiao Yang,
> Hi!
> > If the value of max_user_namespaces is set to 10 but more than
> > 10 user namspaces are currently used on system. In this case,
> > these tests fail with ENOSPC. for example:
> > # lsns -t user -n | wc -l
> > 17
> > # ./fanotify17
> > ...
> > fanotify17.c:174: TINFO: Test #0: Global groups limit in init user ns
> > fanotify17.c:130: TPASS: Created 128 groups - below groups limit (128)
> > fanotify17.c:174: TINFO: Test #1: Global groups limit in privileged user ns
> > fanotify17.c:154: TFAIL: unshare(CLONE_NEWUSER) failed: ENOSPC (28)
> > tst_test.c:452: TBROK: Invalid child (6958) exit value 1
> That's strange the test seems to work for me even if it's over the
> limit.
> $ lsns -t user -n | wc -l
> 14
I'm able to reproduce as well on VM.
I get problems with 9 for fanotify17 ...
# for i in {0..7}; do unshare -U & done
# lsns -t user -n | wc -l
9
# ./fanotify17
...
fanotify17.c:154: TFAIL: unshare(CLONE_NEWUSER) failed: ENOSPC (28)
tst_test.c:452: TBROK: Invalid child (1916) exit value 1
and with 10 for getxattr05:
# unshare -U &
# lsns -t user -n | wc -l
10
# ./getxattr05
getxattr05.c:88: TPASS: Got same data when acquiring the value of system.posix_acl_access twice
getxattr05.c:88: TPASS: Got same data when acquiring the value of system.posix_acl_access twice
getxattr05.c:88: TPASS: Got same data when acquiring the value of system.posix_acl_access twice
> I suppose that since the test is executed as a root since it has
> .require_root the limits does not apply. It's strange that they apply in
> your case. Which kernel is this?
Testing on 6.12.0-rc4-1.gf83465d-default and 6.11.5-1-default (both openSUSE
Tumbleweed) and 6.9.9-amd64 (Debian).
Yes, root access is required for rw to /proc/sys/user/max_user_namespaces:
getxattr05.c:159: TBROK: Failed to open FILE '/proc/sys/user/max_user_namespaces' for writing: EACCES (13)
getxattr05.c:167: TWARN: Failed to open FILE '/proc/sys/user/max_user_namespaces' for writing: EACCES (13)
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error
2024-09-25 8:49 [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error Xiao Yang
2024-09-26 11:18 ` Cyril Hrubis
@ 2024-11-04 16:45 ` Petr Vorel
2025-01-27 17:14 ` Petr Vorel
2025-04-29 9:47 ` Cyril Hrubis
3 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2024-11-04 16:45 UTC (permalink / raw)
To: Xiao Yang; +Cc: ltp
Hi Cyril, Xiao Yang,
Reviewed-by: Petr Vorel <pvorel@suse.cz>
> BTW, it may be better to get the number of user namespaces in use and then add 10.
Although I thing this suggestion from Xiao Yang would be better.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error
2024-09-25 8:49 [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error Xiao Yang
2024-09-26 11:18 ` Cyril Hrubis
2024-11-04 16:45 ` Petr Vorel
@ 2025-01-27 17:14 ` Petr Vorel
2025-04-29 9:47 ` Cyril Hrubis
3 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2025-01-27 17:14 UTC (permalink / raw)
To: Xiao Yang; +Cc: ltp
Hi Cyril, Li,
> If the value of max_user_namespaces is set to 10 but more than
> 10 user namspaces are currently used on system. In this case,
> these tests fail with ENOSPC. for example:
> # lsns -t user -n | wc -l
> 17
> # ./fanotify17
> ...
> fanotify17.c:174: TINFO: Test #0: Global groups limit in init user ns
> fanotify17.c:130: TPASS: Created 128 groups - below groups limit (128)
> fanotify17.c:174: TINFO: Test #1: Global groups limit in privileged user ns
> fanotify17.c:154: TFAIL: unshare(CLONE_NEWUSER) failed: ENOSPC (28)
> tst_test.c:452: TBROK: Invalid child (6958) exit value 1
> Try to fix the issue by increasing the default value of
> max_user_namespaces by 10.
How about merging this before release? I was able to reproduce:
https://lore.kernel.org/ltp/20241104163845.GA1417282@pevik/
Kind regards,
Petr
> Signed-off-by: Xiao Yang <ice_yangxiao@163.com>
> ---
> testcases/kernel/syscalls/fanotify/fanotify17.c | 2 +-
> testcases/kernel/syscalls/getxattr/getxattr05.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> diff --git a/testcases/kernel/syscalls/fanotify/fanotify17.c b/testcases/kernel/syscalls/fanotify/fanotify17.c
> index 3ecb31b6e..a6206d953 100644
> --- a/testcases/kernel/syscalls/fanotify/fanotify17.c
> +++ b/testcases/kernel/syscalls/fanotify/fanotify17.c
> @@ -224,7 +224,7 @@ static void setup(void)
> user_ns_supported = 0;
> } else if (!access(MAX_USERNS, F_OK)) {
> SAFE_FILE_SCANF(MAX_USERNS, "%d", &orig_max_userns);
> - SAFE_FILE_PRINTF(MAX_USERNS, "%d", 10);
> + SAFE_FILE_PRINTF(MAX_USERNS, "%d", orig_max_userns + 10);
> }
> /*
> diff --git a/testcases/kernel/syscalls/getxattr/getxattr05.c b/testcases/kernel/syscalls/getxattr/getxattr05.c
> index d9717a695..f1c8e8391 100644
> --- a/testcases/kernel/syscalls/getxattr/getxattr05.c
> +++ b/testcases/kernel/syscalls/getxattr/getxattr05.c
> @@ -156,7 +156,7 @@ static void setup(void)
> user_ns_supported = 0;
> } else if (!access(MAX_USERNS, F_OK)) {
> SAFE_FILE_SCANF(MAX_USERNS, "%d", &orig_max_userns);
> - SAFE_FILE_PRINTF(MAX_USERNS, "%d", 10);
> + SAFE_FILE_PRINTF(MAX_USERNS, "%d", orig_max_userns + 10);
> }
> }
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error
2024-09-25 8:49 [LTP] [PATCH v2] syscalls/{fanotify17, getxattr05}: Fix the ENOSPC error Xiao Yang
` (2 preceding siblings ...)
2025-01-27 17:14 ` Petr Vorel
@ 2025-04-29 9:47 ` Cyril Hrubis
3 siblings, 0 replies; 6+ messages in thread
From: Cyril Hrubis @ 2025-04-29 9:47 UTC (permalink / raw)
To: Xiao Yang; +Cc: ltp
Hi!
> If the value of max_user_namespaces is set to 10 but more than
> 10 user namspaces are currently used on system. In this case,
> these tests fail with ENOSPC. for example:
What about we add a functionality to increment syfs files to the
save_restore API? I guess that this is going to be a pattern that we
have in several tests already.
Should look like (beware untested):
diff --git a/include/tst_sys_conf.h b/include/tst_sys_conf.h
index a221a9a0d..b84f05a50 100644
--- a/include/tst_sys_conf.h
+++ b/include/tst_sys_conf.h
@@ -12,6 +12,7 @@
#define TST_SR_TBROK_RO 0x4
#define TST_SR_SKIP_RO 0x8
#define TST_SR_IGNORE_ERR 0x10
+#define TST_SR_INC 0x20
#define TST_SR_TCONF (TST_SR_TCONF_MISSING | TST_SR_TCONF_RO)
#define TST_SR_TBROK (TST_SR_TBROK_MISSING | TST_SR_TBROK_RO)
diff --git a/lib/tst_sys_conf.c b/lib/tst_sys_conf.c
index 80cd83569..5d1de241a 100644
--- a/lib/tst_sys_conf.c
+++ b/lib/tst_sys_conf.c
@@ -55,6 +55,8 @@ void tst_sys_conf_save_str(const char *path, const char *value)
int tst_sys_conf_save(const struct tst_path_val *conf)
{
char line[PATH_MAX];
+ char inc_val[32];
+ const char *new_val = conf->val;
int ttype, iret;
FILE *fp;
void *ret;
@@ -105,7 +107,35 @@ int tst_sys_conf_save(const struct tst_path_val *conf)
tst_sys_conf_save_str(conf->path, line);
- if (!conf->val)
+
+ if (conf->flags & TST_SR_INC) {
+ long orig, inc;
+
+ if (!conf->val) {
+ tst_brk(TBROK, "Increment value not defined!");
+ }
+
+ if (tst_parse_long(line, &orig, LONG_MIN, LONG_MAX)) {
+ tst_brk(TBROK | TERRNO,
+ "Failed to convert '%s' to long",
+ conf->path);
+ }
+
+ if (tst_parse_long(line, &inc, LONG_MIN, LONG_MAX)) {
+ tst_brk(TBROK | TERRNO,
+ "Failed to convert increment (%s) for '%s' to long",
+ conf->val, conf->path);
+ }
+
+ //TODO: Overflow?
+ orig += inc;
+
+ snprintf(inc_val, sizeof(inc_val), "%li", orig);
+
+ new_val = inc_val;
+ }
+
+ if (!new_val)
return 0;
fp = fopen(conf->path, "w");
@@ -116,7 +146,7 @@ int tst_sys_conf_save(const struct tst_path_val *conf)
return 0;
}
- iret = fputs(conf->val, fp);
+ iret = fputs(new_val, fp);
if (iret < 0) {
print_error(__LINE__, conf->flags & TST_SR_IGNORE_ERR,
After this patch the val in tst_path_val is going to be interpreted as
an increment with TST_SR_INC flag.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 6+ messages in thread