linux-kernel - Re: Ping: [PATCH] x86/PAT: have pat_enabled() properly reflect state when running on e.g. Xen

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: <b350e874-62eb-7ecc-0cf7-b7ce62e65db3@suse.com>
Date:   Tue, 5 Jul 2022 13:02:08 +0200
From:   Jan Beulich <jbeulich@...e.com>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Andrew Lutomirski <luto@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        the arch/x86 maintainers <x86@...nel.org>,
        Juergen Gross <jgross@...e.com>
Subject: Re: Ping: [PATCH] x86/PAT: have pat_enabled() properly reflect state
 when running on e.g. Xen

On 05.07.2022 12:57, Thorsten Leemhuis wrote:
> [CCing tglx, mingo, Boris and Juergen]
> 
> On 04.07.22 14:26, Jan Beulich wrote:
>> On 04.07.2022 13:58, Thorsten Leemhuis wrote:
>>> On 25.05.22 10:55, Jan Beulich wrote:
>>>> On 28.04.2022 16:50, Jan Beulich wrote:
>>>>> The latest with commit bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT
>>>>> with pat_enabled()") pat_enabled() returning false (because of PAT
>>>>> initialization being suppressed in the absence of MTRRs being announced
>>>>> to be available) has become a problem: The i915 driver now fails to
>>>>> initialize when running PV on Xen (i915_gem_object_pin_map() is where I
>>>>> located the induced failure), and its error handling is flaky enough to
>>>>> (at least sometimes) result in a hung system.
>>>>>
>>>>> Yet even beyond that problem the keying of the use of WC mappings to
>>>>> pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
>>>>> graphics frame buffer accesses would have been quite a bit less
>>>>> performant than possible.
>>>>>
>>>>> Arrange for the function to return true in such environments, without
>>>>> undermining the rest of PAT MSR management logic considering PAT to be
>>>>> disabled: Specifically, no writes to the PAT MSR should occur.
>>>>>
>>>>> For the new boolean to live in .init.data, init_cache_modes() also needs
>>>>> moving to .init.text (where it could/should have lived already before).
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@...e.com>
>>>>
>>>> The Linux kernel regression tracker is pestering me because things are
>>>> taking so long (effectively quoting him), and alternative proposals
>>>> made so far look to have more severe downsides.
>>>
>>> Has any progress been made with this patch? It afaics is meant to fix
>>> this regression, which ideally should have been fixed weeks ago (btw:
>>> adding a "Link:" tag pointing to it would be good):
>>> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
>>>
>>> According to Juergen it's still needed:
>>> https://lore.kernel.org/lkml/c5515533-29a9-9e91-5a36-45f00f25b37b@suse.com/
>>>
>>> Or was a different solution found to fix that regression?
>>
>> No progress and no alternatives I'm aware of.
> 
> Getting closer to the point where I need to bring this to Linus
> attention. I hope this mail can help avoiding this.
> 
> Jan, I didn't follow this closely, but do you have any idea why Dave,
> Luto, and Peter are ignoring this?

No, I don't.

> Is reverting bdd8b6c98239 a option to get the regression fixed?

No, that change is warranted.

> Would a repost maybe help getting this rolling again?

No idea, but it doesn't seem very likely - there have been ample pings
and alike.

Jan