From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5D80738197D3; Fri, 16 Sep 2022 15:39:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D80738197D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663342756; bh=KrjbJDyHvWsvOyIdEf4dWsHra5S5iuhDma7SVoirFSk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=b7b3hOK3DYAUjKMLV0KBKuK79KjBIH/4Ubeb5FPiik9/FsQKyypyLcwLnS7ZIOoQK umV8eqrqeznidcERPpugpeBozrqtztLTOWELBYWtfiROqA5mcE+KbuG3JvxOSm7g0F 1i5NNFluHWlBckvhDg/gBz3qQnzdKdSk02cpVRVg= From: "danglin at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/29537] [2.34 regression]: Alignment issue on m68k when using futexes on qemu-user Date: Fri, 16 Sep 2022 15:39:15 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.34 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: danglin at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29537 John David Anglin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danglin at gcc dot gnu.org --- Comment #8 from John David Anglin --- (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. >=20 > If an architecture needs higher alignment for locks then I strongly sugge= st > 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 consisten= tly > in our kernel helper (kernel aided emulation of compare-and-swap) and ins= ide > 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 fu= tex > 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 outs= ide 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 mem= ory. Having a 16-byte alignment for locks is somewhat problematic. Malloc data is over aligned and this causes problems for some packages which check alignme= nt. --=20 You are receiving this mail because: You are on the CC list for the bug.=