From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEC37C54EBC for ; Wed, 4 Jan 2023 13:55:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DECA8E0002; Wed, 4 Jan 2023 08:55:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18E568E0001; Wed, 4 Jan 2023 08:55:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02EFC8E0002; Wed, 4 Jan 2023 08:55:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E3DAE8E0001 for ; Wed, 4 Jan 2023 08:55:32 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 878EC1201C0 for ; Wed, 4 Jan 2023 13:55:32 +0000 (UTC) X-FDA: 80317264104.08.79A9D6E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 13844140007 for ; Wed, 4 Jan 2023 13:55:29 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672840530; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yIJljz8ugn36piMPjY+/7ytQilBpuL69ZxtaNd1+BBY=; b=wPXQIy+fjTKn/M24EtBJhQ52pxwo2tes2yHu1hZ6fSJLYuH+uDiKf7fipt9eaAxudahThV zoQO/k5Lgqs7ukAskS/s9wic8A0BLnTt+GHeQDcXvFOooKsNegNsO70Ftv8rmsWK2PA2tt EKiMyJEJp/rqSdkVbcy2OtFEcY+rXp8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672840530; a=rsa-sha256; cv=none; b=gcJps/I65TIpc3N1J89JIqwcU4GP+xrC8zCE3BbRsDx/MWL8IVpFMq9v6r2txFXLcUfA6P ankuYQmSZxHcQQZdf8sjcJinjqQRIEof0MEiSUt5uK70QLkctVbjo2sDJnsdKkQ7/5qIGG zeGPJcI6bW/h7r/w/lBEEtv0lgw0o1U= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9C3741FB; Wed, 4 Jan 2023 05:56:10 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.37.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 297963F587; Wed, 4 Jan 2023 05:55:23 -0800 (PST) Date: Wed, 4 Jan 2023 13:55:20 +0000 From: Mark Rutland To: Arnd Bergmann Cc: Peter Zijlstra , Boqun Feng , Linus Torvalds , Jonathan Corbet , Will Deacon , Catalin Marinas , dennis@kernel.org, Tejun Heo , Christoph Lameter , Heiko Carstens , gor@linux.ibm.com, Alexander Gordeev , borntraeger@linux.ibm.com, svens@linux.ibm.com, Herbert Xu , "David S . Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , joro@8bytes.org, suravee.suthikulpanit@amd.com, Robin Murphy , dwmw2@infradead.org, baolu.lu@linux.intel.com, Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux.dev, Linux-Arch Subject: Re: [RFC][PATCH 05/12] arch: Introduce arch_{,try_}_cmpxchg128{,_local}() Message-ID: References: <20221219153525.632521981@infradead.org> <20221219154119.154045458@infradead.org> <8fea3494-1d1f-4f64-b525-279152cf430b@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 13844140007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 3quu5ykxmhf7374qx8udhxxdbthmpup5 X-HE-Tag: 1672840529-840325 X-HE-Meta: U2FsdGVkX19lVbnOdISXLkGRVjdJivclZYKm6yhj+H+F9rdm4kohxNJ2RoEYZVgUMS9r9H0w+GE1L4U+K1pfXFLdgfGxZqveWMiLbKHxPMbjRUqf5W0N8WeZ7xL362Da4my9DutYmpIl/h+H2+gSC6g84uUc4/6XsEQAts1sBnK0MWuA2Dm5wM+Q4i3EZt6Cmq35HFaQosxXDFubpElaEUL+vMiNul3q4+2wxrly0O09hxDu4JtLhT5L0W74LP79CjWko85JPf7Wj8JBitn0E6AuuvVqrWmr5tCZS1sfVjmQQ8N6Nxam3rCn5BXDirJXlLipkz4JgwNPAqFyLl6Id5xIINgpewVa989GzyfKXSnK8NSwRsXDryswyqMPHgJPioNwTcd+TEO2zotfdzldvCgHUhLfgdFR8ZS31PobINr6R1QWlUOWz+UhbHpsaA724mskvkzdI+U8PhZ8A9bk8x/FIvC8sOeDMI3aD7W3oauZKTfLz8ULN1x77E+JiVQpBranLQidP9mljdhUyGi8MWOhkNOyM3hHaQayIHdmxqhYsGdlnvtKvlPIWpqDKMKkCHsNHQKbMuyl3ohcXuyQ3oj+crLd99PTANvNupoFXtOmjSdNCzNVCMvYTINWheYPjR84yMsaxhGq6W7TZquH0s39hM6124qme7vJtphU3twdacT0VBGvvBp9ve4ltN+033EYatKAbaw1zGfeNuWeIQzaIvb0sciUuDZidRJjlzV3ZZKQJwwkLzUPSXrJ66BqeXN7ZomVXCFDoaVHIg6k5iB8Yt2ms/05frTyfVc6RAiWHSnMtVMFL453BQgJyi18SQgBU7DxK0kuJe4nBE6aR/872zzR6E4ExqhPZd2LdmvN19O1nF5X28y7VJg8yUJWgeN3nV1meR1ictWAeg193hWUUrs+P1EIz55xNP/Mns75e/VDZqkM3XF4D1uRtcVe X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 04, 2023 at 11:36:18AM +0000, Mark Rutland wrote: > On Tue, Jan 03, 2023 at 05:50:00PM +0100, Arnd Bergmann wrote: > > On Tue, Jan 3, 2023, at 17:19, Mark Rutland wrote: > > > On Tue, Jan 03, 2023 at 02:03:37PM +0000, Mark Rutland wrote: > > >> On Tue, Jan 03, 2023 at 01:25:35PM +0000, Mark Rutland wrote: > > >> > On Tue, Dec 20, 2022 at 12:08:16PM +0100, Peter Zijlstra wrote: > > > > >> ... makes GCC much happier: > > > > > >> ... I'll go check whether clang is happy with that, and how far back that can > > >> go, otherwise we'll need to blat the high half with a separate constaint that > > >> (ideally) doesn't end up allocating a pointless address register. > > > > > > Hmm... from the commit history it looks like GCC prior to 5.1 might not be > > > happy with that, but that *might* just be if we actually do arithmetic on the > > > value, and we might be ok just using it for memroy effects. I can't currently > > > get such an old GCC to run on my machines so I haven't been able to check. > > > > gcc-5.1 is the oldest (barely) supported compiler, the minimum was > > last raised from gcc-4.9 in linux-5.15. If only gcc-4.9 and older are > > affected, we're good on mainline but may still want a fix for stable > > kernels. > > Yup; I just wanted something that would easily backport to stable, at least as > far as linux-4.9.y (where I couldn't find the minimum GCC version when I looked > yesterday). I'd missed that we backported commit: dca5244d2f5b94f1 ("compiler.h: Raise minimum version of GCC to 5.1 for arm64") ... all the way back to v4.4.y, so we can assume v5.1 even in stable. The earliest toolchain I could get running was GCC 4.8.5, and that was happy with the __uint128_t cast for the asm, Looking back through the history, the reason for the GCC 5.1 check was that prior to GCC 5.1 GCC would output library calls for arithmetic on 128-bit types, as noted in commit: fb8722735f50cd51 ("arm64: support __int128 on gcc 5+") ... but since we're not doing any actual manipulation of the value, that should be fine. I'll go write a commit message and send that out as a fix. > > I checked that the cross-compiler binaries from [1] still work, but I noticed > > that this version is missing the native aarch64-to-aarch64 compiler (x86 to > > aarch64 and vice versa are there), and you need to install libmpfr4 [2] > > as a dependency. The newer compilers (6.5.0 and up) don't have these problems. > > I was trying the old kernel.org crosstool binaries, but I was either missing a > library (or I have an incompatible version) on my x86_64 host. I'll have > another look today -- thanks for the pointers! It turns out I'd just missed that at some point the prefix used by the kernel.org cross compilers changed from: aarch64-linux-gnu- to: aarch64-linux- ... and I'd become so used to the latter that I was trying to invoke a binary that didn't exist. With the older prefix I could use the kernel.org GCC 4.8.5 without issue. Thanks, Mark.