From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 929963854143 for ; Tue, 30 Aug 2022 16:32:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 929963854143 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pg1-x52d.google.com with SMTP id q9so11145091pgq.6 for ; Tue, 30 Aug 2022 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=688CNAqS9Jbo56KYQXWFgJw2FGDIERE7iu64DuUf24g=; b=qM/8rMt9xwWTMsme7v1nSr+9RHVmpj7yt62ftAkU8Fij4OQlKv9JYNHAO8kKcEKEBE cEg0PmdfGqiI2ux4v5ToKGc6oszuj9JG5orq3PTa4q65C/g9Eibm/TDfytwUnYPVqSpc lL3eVAJbMFyOLodLeSMOzTv5ZD+xLH1HiaoG5rH2T1hPs0TfW/887T1qi44ps2njzq87 qu3n2/jzjaHng4EXu1+lmDHaiP5nrkEj3zx1G7IJSgxR0mt/Iolg+FlLo1uyIrDGVDws M0Nk4lZ5ekzTzeCbNty6JjWPfiqDHx1Fm98CFopQlOSRO3kKaNcW7oSwzpnrZ4ixvFed 1jLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=688CNAqS9Jbo56KYQXWFgJw2FGDIERE7iu64DuUf24g=; b=7DYODcj/2WBbagLiw4AISveHkOKw1mFbG9kaxHjeLAhJYbmnpQveZFNcApJiwuWaUF 3a4XA5/KiR+buHpHvRCgtTQN4xF+iw3lJRoQzn2WORAREsSpNsnid18LaK3jhME3/4El BkpqVJ8z/MqB8SbyhuvxMpvKRbto/oeJAavtmP+pAVPYhGiK+k23rnWI2XoVIyJgb43h qLwBj9G6jVBZY06a0/AxsWXrDdUeja7QE6dFaWMWNKmSZx/P2RoQzT1hmPzwe3OiV4Zb S7UYjRPJzb8lD9xq5fYXH8rb0CSt1iCt7Nl1BqNrRpYWEGt28Bgvij+rvn/gu4tApr4d tTtg== X-Gm-Message-State: ACgBeo0p7sHr3pxVWjrf+wAPdygghk1SghE/9rCydLVcHDo+FMUM6iSF yOMjV4CWLNqVoqQpQ1CjuE5ZTw== X-Google-Smtp-Source: AA6agR77yYfJ1VnBpJ94x9zO+WYh2bipoZAZ1m3DZwibMD2rb/p08Xl7RP36dofW4TnoAH9A8cj4dQ== X-Received: by 2002:a05:6a00:23c1:b0:52e:28f5:4e13 with SMTP id g1-20020a056a0023c100b0052e28f54e13mr22191187pfc.20.1661877162836; Tue, 30 Aug 2022 09:32:42 -0700 (PDT) Received: from [192.168.0.4] ([71.212.157.236]) by smtp.gmail.com with ESMTPSA id u23-20020a1709026e1700b0016cf3f124e1sm9978893plk.234.2022.08.30.09.32.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Aug 2022 09:32:41 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2022 09:32:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] m68: Enforce 4-byte alignment on internal locks (BZ #29537) Content-Language: en-US To: Adhemerval Zanella , libc-alpha@sourceware.org, glaubitz@physik.fu-berlin.de References: <20220830133504.2669323-1-adhemerval.zanella@linaro.org> From: Richard Henderson In-Reply-To: <20220830133504.2669323-1-adhemerval.zanella@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/30/22 06:35, Adhemerval Zanella via Libc-alpha wrote: > The HPPA also requires a 16-byte alignment for locks, although it is > just a historical artifact to keep compatibility with old > implementation. > --- > sysdeps/nptl/libc-lockP.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > 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 > > /* Mutex type. */ > -typedef int __libc_lock_t; > +typedef int __libc_lock_t __LOCK_ALIGNMENT; As Carlos explained, hppa doesn't require 16-byte alignment for kernel-assisted CAS. I was on my way towards testing -/* Mutex type. */ -typedef int __libc_lock_t; +/* Mutex type. + It is a requirement of the futex interface that the data be + naturally aligned. This is almost always already the case + for 'int', but some older ABIs, e.g. m68k, do not. + The pthread types will have been aligned by __LOCK_ALIGNMENT. */ +typedef int __libc_lock_t __attribute__((aligned(4))); r~