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: <Z0nD6NZc3wmq8_v9@sashalap>
Date: Fri, 29 Nov 2024 08:38:48 -0500
From: Sasha Levin <sashal@...nel.org>
To: Pavel Machek <pavel@...x.de>
Cc: 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, 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?

-- 
Thanks,
Sasha