[Bug libc/29537] [2.34 regression]: Alignment issue on m68k when using futexes on qemu-user

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29537

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Adhemerval Zanella from comment #2)
> It seems a real issue, but I am puzzled why we have not see any issue so
> far. I take mostly runs were done in single-core, where hardware did not
> enforce 32-bit alignment with atomic operations.
> 
> A better change would be to use:
> 
> diff --git a/sysdeps/nptl/libc-lockP.h b/sysdeps/nptl/libc-lockP.h
> index d3a6837fd2..9efe962588 100644
> --- a/sysdeps/nptl/libc-lockP.h
> +++ b/sysdeps/nptl/libc-lockP.h
> @@ -34,7 +34,7 @@
>  #include <tls.h>
> 
>  /* Mutex type.  */
> -typedef int __libc_lock_t;
> +typedef int __libc_lock_t __LOCK_ALIGNMENT;
>  typedef struct { pthread_mutex_t mutex; } __rtld_lock_recursive_t;
>  typedef pthread_rwlock_t __libc_rwlock_t;

Does this impact any externally visible ABIs?

> Since __LOCK_ALIGNMENT is defined per architecture if required.  The HPPA
> also requires a 16-byte alignment for locks, although it is just a
> historical artifact to keep compatibility with old implementation.

If an architecture needs higher alignment for locks then I strongly suggest
out-of-line locking in the kernel as we did for parisc. We have an array of
locks that we use to scale the futex locking operations. We pick a lock based
on the low-bit hash of the futex address, and we use that consistently in our
kernel helper (kernel aided emulation of compare-and-swap) and inside the
kernel. This yields a consistent behaviour on SMP where the userspace CAS uses
the same set of lock words for the address as the kernel-side futex CAS. Those
lock words are 16-byte aligned because only load-and-clear-word (ldcw) exists
on parisc and requires the extra alignment for the hardware atomicity to hold.

-- 
You are receiving this mail because:
You are on the CC list for the bug.