| Message ID | YyoghuufsX7+v4e/@mx3210.localdomain |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] hppa: undef __ASSUME_SET_ROBUST_LIST | expand |
On Sep 20 2022, John David Anglin wrote: > QEMU does not support support set_robust_list. Thus, we need > to enable detection of set_robust_list system call. This is actually a generic issue. What are the symptoms?
On 20/09/22 17:20, John David Anglin wrote: > QEMU does not support support set_robust_list. Thus, we need > to enable detection of set_robust_list system call. > > Signed-off-by: John David Anglin <dave.anglin@bell.net> > --- > diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h > index 0cd21ef0fa..079612e4aa 100644 > --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h > +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h > @@ -30,3 +30,6 @@ > > #undef __ASSUME_CLONE_DEFAULT > #define __ASSUME_CLONE_BACKWARDS 1 > + > +/* QEMU does not support set_robust_list. */ > +#undef __ASSUME_SET_ROBUST_LIST > Does it happen only for hppa? If is a generic missing feature maybe we should undef __ASSUME_SET_ROBUST_LIST for all architectures.
* Adhemerval Zanella Netto via Libc-alpha: > On 20/09/22 17:20, John David Anglin wrote: >> QEMU does not support support set_robust_list. Thus, we need >> to enable detection of set_robust_list system call. >> >> Signed-off-by: John David Anglin <dave.anglin@bell.net> >> --- >> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >> index 0cd21ef0fa..079612e4aa 100644 >> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h >> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >> @@ -30,3 +30,6 @@ >> >> #undef __ASSUME_CLONE_DEFAULT >> #define __ASSUME_CLONE_BACKWARDS 1 >> + >> +/* QEMU does not support set_robust_list. */ >> +#undef __ASSUME_SET_ROBUST_LIST >> > > Does it happen only for hppa? If is a generic missing feature maybe we should > undef __ASSUME_SET_ROBUST_LIST for all architectures. I think it's just a 32-bit/64-bit mismatch issue. You can't create 32-bit robust futexes from a 64-bit process because the pointer size in the robust list differs. For non-process-shared mutexes, qemu-user should be able to emulate these futexes in userspace. It already has to intercept thread exit, and it can walk the mutex list at that time. I don't think it makes sense to pessimize bare-metal uses simply because there's a qemu-user limitation. Thanks, Florian
On Sep 21 2022, Florian Weimer via Libc-alpha wrote:
> I think it's just a 32-bit/64-bit mismatch issue.
The endianess must match too.
On 2022-09-21 3:41 a.m., Andreas Schwab wrote: > On Sep 20 2022, John David Anglin wrote: > >> QEMU does not support support set_robust_list. Thus, we need >> to enable detection of set_robust_list system call. > This is actually a generic issue. What are the symptoms? This what Helge found building Debian glibc 2.23 under qemu: glibc is still building but here are some more failures: glibc-2.34/build-tree/hppa-libc/nptl/tst-align-clone.test-result:FAIL: nptl/tst-align-clone glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24-static.test-result:FAIL: nptl/tst-cancel24-static glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24.test-result:FAIL: nptl/tst-cancel24 glibc-2.34/build-tree/hppa-libc/nptl/tst-cancelx17.test-result:FAIL: nptl/tst-cancelx17 glibc-2.34/build-tree/hppa-libc/nptl/tst-cleanupx4.test-result:XFAIL: nptl/tst-cleanupx4 glibc-2.34/build-tree/hppa-libc/nptl/tst-execstack.test-result:FAIL: nptl/tst-execstack glibc-2.34/build-tree/hppa-libc/nptl/tst-getpid1.test-result:FAIL: nptl/tst-getpid1 glibc-2.34/build-tree/hppa-libc/nptl/tst-mutexpi10.test-result:FAIL: nptl/tst-mutexpi10 glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-attr-affinity-fail.test-result:FAIL: nptl/tst-pthread-attr-affinity-fail glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-gdb-attach-static.test-result:FAIL: nptl/tst-pthread-gdb-attach-static glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-gdb-attach.test-result:FAIL: nptl/tst-pthread-gdb-attach glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-timedlock-lockloop.test-result:FAIL: nptl/tst-pthread-timedlock-lockloop glibc-2.34/build-tree/hppa-libc/nptl/tst-robust-fork.test-result:FAIL: nptl/tst-robust-fork tst-cancel24 triggered my interest, so I checked what's doing: #> QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24 ... 2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented) ... This syscall isn't implemented in qemu, and probably won't either. Here is the comment from qemu sources: case TARGET_NR_set_robust_list: case TARGET_NR_get_robust_list: /* The ABI for supporting robust futexes has userspace pass * the kernel a pointer to a linked list which is updated by * userspace after the syscall; the list is walked by the kernel * when the thread exits. Since the linked list in QEMU guest * memory isn't a valid linked list for the host and we have * no way to reliably intercept the thread-death event, we can't * support these. Silently return ENOSYS so that guest userspace * falls back to a non-robust futex implementation (which should * be OK except in the corner case of the guest crashing while * holding a mutex that is shared with another process via * shared memory). */ return -TARGET_ENOSYS; This basically means we never will be able to succeed this test when building glibc on qemu-linux-user - unless we disable such tests, which I think isn't a good idea. Dave
On 21/09/22 09:49, Florian Weimer wrote: > * Adhemerval Zanella Netto via Libc-alpha: > >> On 20/09/22 17:20, John David Anglin wrote: >>> QEMU does not support support set_robust_list. Thus, we need >>> to enable detection of set_robust_list system call. >>> >>> Signed-off-by: John David Anglin <dave.anglin@bell.net> >>> --- >>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>> index 0cd21ef0fa..079612e4aa 100644 >>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>> @@ -30,3 +30,6 @@ >>> >>> #undef __ASSUME_CLONE_DEFAULT >>> #define __ASSUME_CLONE_BACKWARDS 1 >>> + >>> +/* QEMU does not support set_robust_list. */ >>> +#undef __ASSUME_SET_ROBUST_LIST >>> >> >> Does it happen only for hppa? If is a generic missing feature maybe we should >> undef __ASSUME_SET_ROBUST_LIST for all architectures. > > I think it's just a 32-bit/64-bit mismatch issue. You can't create > 32-bit robust futexes from a 64-bit process because the pointer size in > the robust list differs. For non-process-shared mutexes, qemu-user > should be able to emulate these futexes in userspace. It already has to > intercept thread exit, and it can walk the mutex list at that time. > > I don't think it makes sense to pessimize bare-metal uses simply because > there's a qemu-user limitation. Should we revert the hppa fix then?
On Sep 21 2022, John David Anglin wrote: > tst-cancel24 triggered my interest, so I checked what's doing: > #> QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24 > ... > 2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented) This test doesn't fail for me for riscv64 with qemu. Others on your list also do not fail here. > This basically means we never will be able to succeed this test > when building glibc on qemu-linux-user - unless we disable such tests, > which I think isn't a good idea. We could try to detect the situation and mark them as unsupported.
On 2022-09-21 10:05 a.m., Andreas Schwab wrote: > On Sep 21 2022, John David Anglin wrote: > >> tst-cancel24 triggered my interest, so I checked what's doing: >> #> QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24 >> ... >> 2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented) > This test doesn't fail for me for riscv64 with qemu. Others on your > list also do not fail here. It depends on the kernel version reported by qemu on riscv: /* No support for PI mutexes or robust futexes before 4.20. */ #if __LINUX_KERNEL_VERSION < 0x041400 # undef __ASSUME_SET_ROBUST_LIST #endif
On Sep 21 2022, John David Anglin wrote: > On 2022-09-21 10:05 a.m., Andreas Schwab wrote: >> On Sep 21 2022, John David Anglin wrote: >> >>> tst-cancel24 triggered my interest, so I checked what's doing: >>> #> QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24 >>> ... >>> 2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented) >> This test doesn't fail for me for riscv64 with qemu. Others on your >> list also do not fail here. > It depends on the kernel version reported by qemu on riscv: > > /* No support for PI mutexes or robust futexes before 4.20. */ > #if __LINUX_KERNEL_VERSION < 0x041400 > # undef __ASSUME_SET_ROBUST_LIST > #endif Ah yes, it's compiled with --enable-kernel=4.15.
* Adhemerval Zanella Netto: > On 21/09/22 09:49, Florian Weimer wrote: >> * Adhemerval Zanella Netto via Libc-alpha: >> >>> On 20/09/22 17:20, John David Anglin wrote: >>>> QEMU does not support support set_robust_list. Thus, we need >>>> to enable detection of set_robust_list system call. >>>> >>>> Signed-off-by: John David Anglin <dave.anglin@bell.net> >>>> --- >>>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>>> index 0cd21ef0fa..079612e4aa 100644 >>>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h >>>> @@ -30,3 +30,6 @@ >>>> >>>> #undef __ASSUME_CLONE_DEFAULT >>>> #define __ASSUME_CLONE_BACKWARDS 1 >>>> + >>>> +/* QEMU does not support set_robust_list. */ >>>> +#undef __ASSUME_SET_ROBUST_LIST >>>> >>> >>> Does it happen only for hppa? If is a generic missing feature maybe we should >>> undef __ASSUME_SET_ROBUST_LIST for all architectures. >> >> I think it's just a 32-bit/64-bit mismatch issue. You can't create >> 32-bit robust futexes from a 64-bit process because the pointer size in >> the robust list differs. For non-process-shared mutexes, qemu-user >> should be able to emulate these futexes in userspace. It already has to >> intercept thread exit, and it can walk the mutex list at that time. >> >> I don't think it makes sense to pessimize bare-metal uses simply because >> there's a qemu-user limitation. > > Should we revert the hppa fix then? Probably? It seems to be an emulation-only problem. Thanks, Florian
diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h index 0cd21ef0fa..079612e4aa 100644 --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h @@ -30,3 +30,6 @@ #undef __ASSUME_CLONE_DEFAULT #define __ASSUME_CLONE_BACKWARDS 1 + +/* QEMU does not support set_robust_list. */ +#undef __ASSUME_SET_ROBUST_LIST
QEMU does not support support set_robust_list. Thus, we need to enable detection of set_robust_list system call. Signed-off-by: John David Anglin <dave.anglin@bell.net> ---