From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B045B391E5D for ; Tue, 10 Mar 2026 14:11:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773151869; cv=none; b=ra0L7yYy3YH7KX4vVCWPxXTdiTOXLMMi5Ef50Lmoc4Szy/CjVvyW4gTqCrSaCkFFA6NBphlzTZspO+A5ispvKCciEs3uK48M3YrdrGhjyqm7G3RwkgACJu44iKyxSDTxNHYFe8ZdJdiVnBfgQACDJqillKP7oY57oGR3Q6H5Fr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773151869; c=relaxed/simple; bh=FOWM1jThBF4LXes97tpS461gjq/mwraEDfx3s89RFZY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UbiBiK84VVLFQLWZc1yYTXusJfjlVsej4sqgTl4LM8nQBVrL90Yv+NyIkkm7jOGYVkSIvPWV5LdrU8F/Bw3U91Ybwdhb43Mk2gtIRkfIfPQvM7SB+Iv+m6GNNemMbzfpoC4p25ioQ3EQWtGiYyztlFyKxJb4ESWK7v76YppMOTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eloCmkqB; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eloCmkqB" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48374014a77so153579575e9.3 for ; Tue, 10 Mar 2026 07:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773151866; x=1773756666; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=D2fB083rJxHKCgt6tIKc2X0OTGuC1Vw3gEz2TExPwrY=; b=eloCmkqB03pL8qJwN28Ql3x/jRmlbL+c0uqmztkupV/C9sTW4I+2fXXj40bqAE4TTg SAm8dwDe9Ib6SSZmZe3TN/+gLG15q/5vxVz5F0ClMVM4d1GjtOIoeJJ+YB3m67bag1I5 nwefvuJpLHcgMgTtFO59d9eI6RPrKSDyiyODwvWAsBNM/MvXjHlLkXGOdQJK6VM1WgmD bo8kXnFcsUkP/WwJCMZa9O0iZGHxEsDclDBDuUVsc1JqNqCEx21GsxpWjUbPyKrTKlbn 7P/5d7CxbMagz/2yBxY6Yw/sL5EAGigYlGF6RogkQLPLzaJj/CPKXjsZESLVrTy/xKt/ Td7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773151866; x=1773756666; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=D2fB083rJxHKCgt6tIKc2X0OTGuC1Vw3gEz2TExPwrY=; b=cHp/zBCr9IkpLDtL82QvRtxSWkb5XWixUc6dkXWRfVRmwNgdhrjgI+yXmLkOIwiywf x+RVEGJ48cDc6apTXW9yMkX3TW8eWNbILaYtKwz6QT1sdYf/JcdZQ57wn4wfktPaYXbT uIk0psuWg/LdjOBBF1I5wWdjGC8DvunuvQmtZby1Fmilx1PU/1kCoqhcR48gHww6g9v9 7GHSDFHIGS5XhUHvF+qSeS/iS/pZaJxiDACoFXwkpOpe10aHZIe4JMakeh8ApHfat0ev Psms4iW99IO7Y63k/aUTvSEHEHWqbYTlLEsgLvm6KkZHpGPU0goJnXOXGJXFWWAxNg2z 2LoQ== X-Forwarded-Encrypted: i=1; AJvYcCV1Nm9AAvyYtnOuDKNDG2fi7zlgrluSRlWIQ3CafBW8HpgtOP5X7XFxOAOmgWu2qgyvTjO+wCp+XHjB3Y4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7iKF+1shrnQFj0Ip7zxvnqLKKceeGPU13QM8Q1Fs1k3ePyKe/ D8hRGEU84C2IaG1ZFIaz/xvpl8exm1wKVGFChU9T85jGYNWsCgIDjdP2 X-Gm-Gg: ATEYQzy1X/8tFoU4mtC3aO7XF13u2liD2qU4/+CMyhS0eZLxpVXtTdXYpxHtGluEZG+ 7oGap1R9RyVZ+UvSbaYvycKDv1GcSuDfDeXJ9j7qu3+3sqAd/TBdL5pv34yyQ+nzxBp5f8ISlsz jNBXo9Ot6xBDWp4VkKySM6Tzlnl3JNkmG9BdRg3NsAhq/FaRkD3S3YWA9U6OaQEcbDOuGB5GMe1 g4V5ZhrHOlB1OGsipIIG1JA32TAPrdk6ufEriXTQDyj9oCr6uQ71E6nODgaN0PImoJtSgd4pcw0 BoNauaMCUBZqtRzzCkMNrOsvv3O2gmhAX2PpaV/bsP/AvkjRrWW2apCzaj2duzZFb0c2r0K6/Kx rQGtoG5XHarJb9pP8buPYPSo/HUWEgWE2oleDls3hbzd764gYIB7f0quhkPyfNvrHWOpIR6jhIr Zny5UN+Z5hujW/uTIUyd2bJgbKW9wqEuMy/U9+KpcnU/n2+QkJIDqfCle1HsnfDdSVLh2iTU0iO kU= X-Received: by 2002:a05:600c:4747:b0:485:4006:960c with SMTP id 5b1f17b1804b1-485400697aamr91905085e9.16.1773151866019; Tue, 10 Mar 2026 07:11:06 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541a8d4desm76056715e9.8.2026.03.10.07.11.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 07:11:05 -0700 (PDT) Date: Tue, 10 Mar 2026 14:11:04 +0000 From: David Laight To: Peter Zijlstra Cc: Uros Bizjak , x86@kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: Re: [PATCH -tip 1/3] x86/fsgsbase: Remove unnecessary "memory" clobbers from FS/GS base accessors Message-ID: <20260310141104.4c57ea79@pumpkin> In-Reply-To: <20260310102742.GU1282955@noisy.programming.kicks-ass.net> References: <20260310082142.93834-1-ubizjak@gmail.com> <20260310102742.GU1282955@noisy.programming.kicks-ass.net> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 10 Mar 2026 11:27:42 +0100 Peter Zijlstra wrote: > On Tue, Mar 10, 2026 at 09:21:22AM +0100, Uros Bizjak wrote: > > The rdfsbase() and rdgsbase() helpers currently include a "memory" clobber > > in their inline assembly definitions. However, the RDFSBASE and RDGSBASE > > instructions only read the FS/GS base MSRs into a general-purpose register > > and do not access memory. As such, the "memory" clobber is unnecessary. > > The point isn't that this accesses memory, but that prior or later > accesses would end up at different memory locations (as would happen > when setting the per-cpu segment. Don't they need a "memory" clobber to stop them being moved the other side of a request to set the relevant register? In effect the [fg]sbase register has to be treated like a memory location. Given that a memory clobber often makes little (or no) difference to the generated code it is probably better to be safe and leave the clobber in place. If the memory clobber does make a significant difference (unlikely here) it can often be mitigated by changing the source code to not rely on CSE. David > > Anyway, aside from that nit, yes these 3 patches look good to me. > > > > > No functional change intended. > > > > Signed-off-by: Uros Bizjak > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: Borislav Petkov > > Cc: Dave Hansen > > Cc: "H. Peter Anvin" > > Cc: "Peter Zijlstra (Intel)" > > --- > > arch/x86/include/asm/fsgsbase.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h > > index ab2547f97c2c..70ff4ef457b1 100644 > > --- a/arch/x86/include/asm/fsgsbase.h > > +++ b/arch/x86/include/asm/fsgsbase.h > > @@ -25,7 +25,7 @@ static __always_inline unsigned long rdfsbase(void) > > { > > unsigned long fsbase; > > > > - asm volatile("rdfsbase %0" : "=r" (fsbase) :: "memory"); > > + asm volatile("rdfsbase %0" : "=r" (fsbase)); > > > > return fsbase; > > } > > @@ -34,7 +34,7 @@ static __always_inline unsigned long rdgsbase(void) > > { > > unsigned long gsbase; > > > > - asm volatile("rdgsbase %0" : "=r" (gsbase) :: "memory"); > > + asm volatile("rdgsbase %0" : "=r" (gsbase)); > > > > return gsbase; > > } > > -- > > 2.53.0 > > >