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

["danglin at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #8 from John David Anglin <danglin at gcc dot gnu.org> ---
(In reply to Carlos O'Donell from comment #3)
> > > 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.

I just want to say that the parisc CAS implementation is subtle and it took
years to get it right. Page faults need to be disabled around the CAS
operation. Some mechanism is needed to handle COW breaks in the kernel outside
the critical region. Fortunately, parisc has a stby,e instruction. When the
effective address addresses the leftmost byte of a word, it does not write to
the effective address but it triggers all the exceptions that a write would.
Thus, it can be used to trigger a COW break without actually writing to memory.

Having a 16-byte alignment for locks is somewhat problematic. Malloc data is
over aligned and this causes problems for some packages which check alignment.

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