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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A83D2C54E67 for ; Tue, 26 Mar 2024 23:55:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cg3+aHme8e/W/lhmKDefW2TsK6kA+9/bbh2wct1WJqg=; b=gi4SNCiuZZGHVJ 9gyaqBZNayU6TT1uxd6qKDjximXy25PnnOa7fyr//vTRsHgnwhCPGp3PeXTgDOlv8lCeDLcD+ZtjZ OeJQKQ0uEz7N45ePDu9E2++1ZbzATslGZl1uudhRWisn6Xhk+P4TEnAdnyASt92cnl5WqtxoW0ssC CoHeTbb8AUbwC1HHJfkh8ksRYMCruZZChT8zWP8EJnMA5Kb8Khb4SQmqZLYbafps0kijcPApqmBgs lvhEKFkn0gR4RVQXrCF+gkA2R/uu03pxCWJXD6aXKx5+7vNGbAbUy/+NrVQFrulDn8kPgh/vbi7WF xBTvd734/ygWkquO1XJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpGdm-00000006uyG-2Vwu; Tue, 26 Mar 2024 23:55:39 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpGdi-00000006uxm-3WXE for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2024 23:55:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 12133614A3; Tue, 26 Mar 2024 23:55:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41B7AC433F1; Tue, 26 Mar 2024 23:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711497331; bh=XKStsCOzkotx7kNzQzBgNXtmKrg6ADCEipbqJ05Zk2I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a4WKHeMUQ48Igkkl/q1NoylCiTG6z2eDJ45/zUGMi5x5KsB7pLvmZPdYnaopOXW/O +O0F5epRQhaZsZ08admEQcy2D+yG75IL1nZF3b9z/vBZOuVo50Rul3REyv11cZ+haq BRsQGeE6isGRLPytpIrOgUgPA3Gwyr7kl7CZajZs0kW9ZvH9CH0EKmHP3LEV9njrvu +oRpMJwyraiG0xiuLOCaRHDfu0vg2Kyc2BdyY1X450q/BhKSIL2CkbBxYCbDWHI9Sy 6rwQ43NLB6bAcZgPnxR/90/IkvJiNj6e4y4TCImLijrpM90CnYZUrrBJoVFehwRR5J uYP66t2Ikj/xA== Date: Tue, 26 Mar 2024 16:55:29 -0700 From: Nathan Chancellor To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, arnd@arndb.de, linus.walleij@linaro.org, Ard Biesheuvel , stable@kernel.org Subject: Re: [PATCH] ARM: vfp: use asm volatile for FP control register accesses Message-ID: <20240326235529.GA2025585@dev-arch.thelio-3990X> References: <20240318093004.117153-2-ardb+git@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240318093004.117153-2-ardb+git@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240326_165534_956871_F0B1F724 X-CRM114-Status: GOOD ( 21.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 18, 2024 at 10:30:05AM +0100, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > Clang may reorder FP control register reads and writes, due to the fact > that the inline asm() blocks in the read/write wrappers are not volatile > qualified, and the compiler has no idea that these reads and writes may > have side effects. > > In particular, reads of FPSCR may generate an UNDEF exception if a > floating point exception is pending, and the FP emulation code in > VFP_bounce() explicitly clears FP exceptions temporarily in order to be > able to perform the emulation on behalf of user space. This requires > that the writes to FPEXC are never reordered with respect to accesses to > other FP control registers, such as FPSCR. > > So use asm volatile for both the read and the write helpers. > > Cc: > Signed-off-by: Ard Biesheuvel This seems reasonable to me based on my understanding of GCC's documentation. However, their documentation states "the compiler can move even volatile asm instructions relative to other code, including across jump instructions" and I feel like there was some discussion around this sentence in the past but I can't remember what the conclusion was, although I want to say Clang did not have the same behavior. Regardless: Acked-by: Nathan Chancellor I am just curious, how was this discovered or noticed? Was there a report I missed? > --- > arch/arm/vfp/vfpinstr.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h > index 3c7938fd40aa..c4ac778e6fc9 100644 > --- a/arch/arm/vfp/vfpinstr.h > +++ b/arch/arm/vfp/vfpinstr.h > @@ -66,14 +66,14 @@ > > #define fmrx(_vfp_) ({ \ > u32 __v; \ > - asm(".fpu vfpv2\n" \ > + asm volatile(".fpu vfpv2\n" \ > "vmrs %0, " #_vfp_ \ > : "=r" (__v) : : "cc"); \ > __v; \ > }) > > #define fmxr(_vfp_,_var_) \ > - asm(".fpu vfpv2\n" \ > + asm volatile(".fpu vfpv2\n" \ > "vmsr " #_vfp_ ", %0" \ > : : "r" (_var_) : "cc") > > -- > 2.39.2 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel