[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6b40ecc3-a2d3-3efd-4a19-2faf737f098b@leemhuis.info>
Date: Tue, 16 Aug 2022 16:41:16 +0200
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Chuck Zmudzinski <brchuckz@...scape.net>
Cc: jbeulich@...e.com, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Pavel Machek <pavel@....cz>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
regressions@...ts.linux.dev, xen-devel@...ts.xenproject.org,
x86@...nel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, Juergen Gross <jgross@...e.com>
Subject: Re: [PATCH 0/3] x86: make pat and mtrr independent from each other
On 15.08.22 20:17, Chuck Zmudzinski wrote:
> On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
>
>> the right people have the issue on their radar again; give them time to
>> breath and work out a solution: it's not something that can be fixed
>> easily within a few minutes by one person alone, as previous discussions
>> have shown (also keep in mind that the merge window was open until
>> yesterday, which keeps many maintainers quite busy).
>>
>> And FWIW: I've seen indicators that a solution to resolve this is
>> hopefully pretty close now.
>
> That's good to know. But I must ask, can you provide a link to a public
> discussion that indicates a fix is close?
I just searched for the commit id of the culprit yesterday like this:
https://lore.kernel.org/all/?q=bdd8b6c982*
Which brought me to this message, which looks like Boris applied a
slightly(?) modified version of Jan's patch to a branch that afaik is
regularly pushed to Linus:
https://lore.kernel.org/all/166055884287.401.612271624942869534.tip-bot2@tip-bot2/
So unless problems show up in linux-next I expect this will land in
master soon (and a bit later be backported to stable due to the CC
stable tag).
> Or do you know a fix is close
> because of private discussions? That distinction is important to me
> because open source software is much less useful to me if the solutions
> to problems are not discussed openly (except, of course, for solutions
> to security vulnerabilities that are not yet public).
You IMHO are expecting a bit too much here IMHO. Solutions to problems
in open source software get discussed on various, sometimes private
channels all the time. Just take conferences for example, where people
discuss them during talks, meetings, or in one-to-ones over coffee;
sometimes they are the only way to solve complex problems. But as you
can see from above link it's not like anybody is trying to sneak things
into the kernel.
Ciao, Thorsten
Powered by blists - more mailing lists