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 EF818C54EBC for ; Tue, 10 Jan 2023 11:27:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 475E98E0002; Tue, 10 Jan 2023 06:27:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 425798E0001; Tue, 10 Jan 2023 06:27:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2ECB38E0002; Tue, 10 Jan 2023 06:27:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1FA2C8E0001 for ; Tue, 10 Jan 2023 06:27:40 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CADCC140BC3 for ; Tue, 10 Jan 2023 11:27:39 +0000 (UTC) X-FDA: 80338664238.20.BEE750E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 0C0E6A0006 for ; Tue, 10 Jan 2023 11:27:37 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf25.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=1673350058; 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=sL6J5Ywlc2KrfJCARO65wFjokXCwDNaUu1iFhyIVwlg=; b=7p8GWZ0Aajbm3ItKseGca6tRJnZBWhgUcfJaQQ7TVvos6FxUKgWqu/c++j68fKwAF9NCYY b5HjVD0xHvUj7oix64Z69rL/73weJBG6f6DFG8+sYHOa8GfsCZCvKuZzWLPYiaHueLV+ze TPHSSqVACXANKHDYmP8KLsD/nBDYWN4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf25.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=1673350058; a=rsa-sha256; cv=none; b=1bxb0wLICzVv+Ta79awf1aKF1OIB7CB/ME09vnjYYS0ySmAsf9AZz9bJJV5MQ1oXTEPVid taXh3pOO5XCc6ze5hLCRZIiFRaqERQgbjyQar6VMtgXNQBuK5GarG/Uij9s7m6GIBBbWIn AoSyt0p1LhoH4keilHgymNzSVaTO5K4= 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 064784B3; Tue, 10 Jan 2023 03:28:19 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.46.95]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE6AE3F587; Tue, 10 Jan 2023 03:27:30 -0800 (PST) Date: Tue, 10 Jan 2023 11:27:28 +0000 From: Mark Rutland To: Peter Zijlstra Cc: Heiko Carstens , Thomas Richter , torvalds@linux-foundation.org, corbet@lwn.net, will@kernel.org, boqun.feng@gmail.com, catalin.marinas@arm.com, dennis@kernel.org, tj@kernel.org, cl@linux.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, Herbert Xu , davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, joro@8bytes.org, suravee.suthikulpanit@amd.com, robin.murphy@arm.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, Arnd Bergmann , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, Andrew Morton , vbabka@suse.cz, roman.gushchin@linux.dev, 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@vger.kernel.org Subject: Re: [RFC][PATCH 08/12] s390: Replace cmpxchg_double() with cmpxchg128() Message-ID: References: <20221219153525.632521981@infradead.org> <20221219154119.352918965@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0C0E6A0006 X-Stat-Signature: bwoz7rm1wjm85bwargbyyphoswzosjud X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673350057-656800 X-HE-Meta: U2FsdGVkX19XarAx1YzrFot1bEpyy3hBoFC3WcFfzfRZLfxajuTg8iTXI6vcXjVdWe9o7TsaZT3ymoZsRUZYXLrb90ee/z/ApJXnjIRmEkQk++mrYj+zJj0vB1aueJ9tHUZU0/oqf+rLspVptY+usjoPi+rTlTrL93sBo2dJC+jXFtVc4EDEJJ969aK7byfcZOxeknM56tmPyRjNvL8b1OOTKMQzPDCdZSobd4212S9BADMrFh/y74rU0L4yiVLaKCBwidrcibFJ5Fo7cUzZ4XZJungu9n6Zhs15/V2D7GXUdjdGaPKeL/T9cx24P9RibRLd+kmugMKxwl8t5vUxvlpf0SI5xB1WZXRcM/G+V4eYYw2SP6Z+M+vuz+mAe7wbq2nSA5d70m1NXlZE+P79QtkEZIoV0IAWehN7p0i/OxR9b6iBN3t6evJq+FrrSl9Yi3EYRiRV7jalMgjhfWoDFZZ7GmIHQuXkjILsCA3ku1+YTw6W+YwbJnWzSrDpzBVyehBoQ7pCDAIWoezzSnDWjX3U0rwYnI8AmyAzguuAtkE/LzH19ZlmXvqzUsyPiVF3kesiFp7TkEP44kGtM6lQOy7bhtsDaEh+ODDn+bAtnmML1s3GrG7XcEHZlW5SgrnR5buP2W87HwgtnwVgHWEIl+z3LXckd3S0rRyaucR4J3jevWpWU3G3vijEa9tTYrngAfsYUHKfkCVh4b8vjv3AN+lo0YZqhFDv1TF8ZS6U5/gSr9ZZm/nWNncqoNn7KJXh1eZW5vYTXaYMrd0Kg6ZZyxoiy7M4UE1FK2CaoiXY9PHRCby6T6+CSjH0Sg7d3uwnPr/TqiSxofhHzWI3XRamhDEA+uhKEI3kPtIEcYsJXF0ySriwMO551JreCkg5dHRPUjkgSlHAf6bARzLhLhxQ/xvi2FAU9lSA1PyBRll7F4uqgCCmL5VT/9O/qBzAzBab 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 Tue, Jan 10, 2023 at 09:32:55AM +0100, Peter Zijlstra wrote: > On Tue, Jan 10, 2023 at 08:23:05AM +0100, Heiko Carstens wrote: > > > So, Alexander Gordeev reported that this code was already prior to your > > changes potentially broken with respect to missing READ_ONCE() within the > > cmpxchg_double() loops. > > Unless there's an early exit, that shouldn't matter. If you managed to > read garbage the cmpxchg itself will simply fail and the loop retries. I don't think that's true; without READ_ONCE() the compiler could (but is very unlikely to) read multiple times, and that could cause problems. For example: | prev = *ptr; | | do { | new = some_function_of(prev); | old = cmpxchg(ptr, prev, new); | } while (old != prev); Could effectively become: | prev1 = *ptr; | prev2 = *ptr; | | do { | new = some_function_of(prev1) | old = cmpxchg(ptr, prev2, new); | } while (old != prev2); ... which would effectively udpate from a stale value, throwing away prev2. That and the two generated reads could be in either order. So I do think it's warranted to use READ_ONCE() for the prev value feeding into a cmpxchg operation, even if that's only for the "once" part rather than lack of tearing. Thanks, Mark.