linux-kernel - Re: [PATCH AUTOSEL 5.15 11/12] x86/barrier: Do not serialize MSR accesses on AMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z0olbd3OYQnlmW+D@duo.ucw.cz>
Date: Fri, 29 Nov 2024 21:34:53 +0100
From: Pavel Machek <pavel@...x.de>
To: Sasha Levin <sashal@...nel.org>
Cc: Pavel Machek <pavel@...x.de>, Borislav Petkov <bp@...en8.de>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
	x86@...nel.org, puwen@...on.cn, seanjc@...gle.com,
	kim.phillips@....com, jmattson@...gle.com, babu.moger@....com,
	peterz@...radead.org, rick.p.edgecombe@...el.com, brgerst@...il.com,
	ashok.raj@...el.com, mjguzik@...il.com, jpoimboe@...nel.org,
	nik.borisov@...e.com, aik@....com, vegard.nossum@...cle.com,
	daniel.sneddon@...ux.intel.com, acdunlap@...gle.com,
	Erwan Velu <erwanaliasr1@...il.com>
Subject: Re: [PATCH AUTOSEL 5.15 11/12] x86/barrier: Do not serialize MSR
 accesses on AMD

On Fri 2024-11-29 08:38:48, Sasha Levin wrote:
> On Fri, Nov 29, 2024 at 10:45:48AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > You've missed the 5.10 mail :)
> > > 
> > > You mean in the flood? ;-P
> > > 
> > > > Pavel objected to it so I've dropped it: https://lore.kernel.org/all/Zbli7QIGVFT8EtO4@sashalap/
> > > 
> > > So we're not backporting those anymore? But everything else? :-P
> > > 
> > > And 5.15 has it already...
> > > 
> > > Frankly, with the amount of stuff going into stable, I see no problem with
> > > backporting such patches. Especially if the people using stable kernels will
> > > end up backporting it themselves and thus multiply work. I.e., Erwan's case.
> > 
> > Well, some people would prefer -stable to only contain fixes for
> > critical things, as documented.
> > 
> > stable-kernel-rules.rst:
> > 
> > - It must fix a problem that causes a build error (but not for things
> >   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> >   security issue, or some "oh, that's not good" issue.  In short, something
> >   critical.
> > 
> > Now, you are right that reality and documentation are not exactly
> > "aligned". I don't care much about which one is fixed, but I'd really
> > like them to match (because that's what our users expect).
> 
> You should consider reading past the first bullet in that section :)
> 
>   - Serious issues as reported by a user of a distribution kernel may also
>     be considered if they fix a notable performance or interactivity issue.
> 
> It sounds like what's going on here, no?

Is it? I'd not expect this to be visible in anything but
microbenchmarks. Do you have user reports hitting this?

It is not like this makes kernel build 10% slower, is it?
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)