[LTP] [PATCH 0/2] syscalls/kcmp03.c: Fix CLONE_IO failure on s390

[LTP] [PATCH 0/2] syscalls/kcmp03.c: Fix CLONE_IO failure on s390

[Alexander Gordeev]

Hi all,

This series fixes the CLONE_IO flag test on s390:

	kcmp03.c:82: FAIL: clone() Failed: EBADF (9)

The reason for the failure is CLONE_IO flag is sign-
extended to unsigned long and CLONE_INTO_CGROUP gets
set unintentionally. The kernel does its job well and
fails the syscall.

The fix is probably wrong, as the right solution needs to
accomodate all archs. I however, post it as a short-term
solution that might work for other archs as well.

Thanks!

Alexander Gordeev (2):
  syscalls/kcmp03.c: Extend clone_type type to unsigned long
  lib/cloner.c: Use __clone instead of clone for s390

 lib/cloner.c                            | 5 +++++
 testcases/kernel/syscalls/kcmp/kcmp03.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
1.8.3.1

[LTP] [PATCH 1/2] syscalls/kcmp03.c: Extend clone_type type to unsigned long

[Alexander Gordeev]

Member clone_type is defined as signed integer type. That
is too small to accomodate CLONE_IO (which conflicts with
the sign bit) and newer clone flags (i.e CLONE_INTO_CGROUP).

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
---
 testcases/kernel/syscalls/kcmp/kcmp03.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/kcmp/kcmp03.c b/testcases/kernel/syscalls/kcmp/kcmp03.c
index 30ac3ec..f36515f 100644
--- a/testcases/kernel/syscalls/kcmp/kcmp03.c
+++ b/testcases/kernel/syscalls/kcmp/kcmp03.c
@@ -31,7 +31,7 @@ static int pid2;
 static void *stack;
 
 static struct tcase {
-	int clone_type;
+	unsigned long clone_type;
 	int kcmp_type;
 } tcases[] = {
 	{CLONE_VM, KCMP_VM},
-- 
1.8.3.1

[LTP] [PATCH 2/2] lib/cloner.c: Use __clone instead of clone for s390

[Alexander Gordeev]

The kernel sys_clone and s390 glibc entry __clone assume
the flags parameter type as unsigned long. However, the
glibc clone wrapper used by ltp_clone helper defines flags
as signed int. That leads to gcc extending CLONE_IO flag of
0x80000000 value to 0xffffffff80000000.

A quick solution for s390 is to skip clone weak alias and
use __clone entry point directly.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
---
 lib/cloner.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/cloner.c b/lib/cloner.c
index 11401f2..1192e4b 100644
--- a/lib/cloner.c
+++ b/lib/cloner.c
@@ -49,6 +49,11 @@ extern int __clone2(int (*fn) (void *arg), void *child_stack_base,
                     size_t child_stack_size, int flags, void *arg,
                     pid_t *parent_tid, void *tls, pid_t *child_tid);
 #endif
+#if defined(__s390__)
+# define clone __clone
+extern int __clone(int (*fn)(void *arg), void *child_stack, unsigned long flags,
+		   void *arg, pid_t *parent_tid, void *tls, pid_t *child_tid);
+#endif
 
 #ifndef CLONE_SUPPORTS_7_ARGS
 # define clone(fn, stack, flags, arg, ptid, tls, ctid) \
-- 
1.8.3.1

[LTP] [PATCH 2/2] lib/cloner.c: Use __clone instead of clone for s390

[Jan Stancek]

----- Original Message -----
> The kernel sys_clone and s390 glibc entry __clone assume
> the flags parameter type as unsigned long. However, the
> glibc clone wrapper used by ltp_clone helper defines flags
> as signed int. That leads to gcc extending CLONE_IO flag of
> 0x80000000 value to 0xffffffff80000000.

Same problem exists on ppc64le. There's a patch proposed to fix this on
kernel side:
  https://lore.kernel.org/lkml/20200507103214.77218-1-christian.brauner@ubuntu.com/

Earlier discussion is here:
  https://sourceware.org/pipermail/libc-alpha/2020-May/113596.html

[LTP] [PATCH 2/2] lib/cloner.c: Use __clone instead of clone for s390

[Petr Vorel]

Hi,

> ----- Original Message -----
> > The kernel sys_clone and s390 glibc entry __clone assume
> > the flags parameter type as unsigned long. However, the
> > glibc clone wrapper used by ltp_clone helper defines flags
> > as signed int. That leads to gcc extending CLONE_IO flag of
> > 0x80000000 value to 0xffffffff80000000.

> Same problem exists on ppc64le. There's a patch proposed to fix this on
> kernel side:
>   https://lore.kernel.org/lkml/20200507103214.77218-1-christian.brauner@ubuntu.com/

> Earlier discussion is here:
>   https://sourceware.org/pipermail/libc-alpha/2020-May/113596.html

OK instead of merging whole patchset we should add git commit hash once this fix is
merged (although no reply since v2 post).

Kind regards,
Petr