linux-kernel - Re: [PATCH v3 0/3] mm: Implement ECC handling for pfn with no struct page

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: <3ss3epklrmwallhd3nih5qqzjk53dcgns5igudtsg4vnnyjyri@ektyavsup6wk>
Date: Tue, 21 Oct 2025 14:54:10 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: ankita@...dia.com, aniketa@...dia.com, vsethi@...dia.com, mochs@...dia.com,
        skolothumtho@...dia.com, linmiaohe@...wei.com, nao.horiguchi@...il.com,
        akpm@...ux-foundation.org, david@...hat.com,
        lorenzo.stoakes@...cle.com, vbabka@...e.cz, rppt@...nel.org,
        surenb@...gle.com, mhocko@...e.com, tony.luck@...el.com, bp@...en8.de,
        rafael@...nel.org, guohanjun@...wei.com, mchehab@...nel.org,
        lenb@...nel.org, kevin.tian@...el.com, alex@...zbot.org,
        cjia@...dia.com, kwankhede@...dia.com, targupta@...dia.com,
        zhiw@...dia.com, dnigam@...dia.com, kjaju@...dia.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-edac@...r.kernel.org, Jonathan.Cameron@...wei.com,
        ira.weiny@...el.com, Smita.KoralahalliChannabasappa@....com,
        u.kleine-koenig@...libre.com, peterz@...radead.org,
        linux-acpi@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v3 0/3] mm: Implement ECC handling for pfn with no struct
 page

* Jason Gunthorpe <jgg@...dia.com> [251021 12:44]:
> On Tue, Oct 21, 2025 at 12:30:48PM -0400, Liam R. Howlett wrote:
> > > enables VM_PFNMAP vmas to map at PMD level. Otherwise, a poison to a PFN
> > > would need breaking the PMD mapping into PTEs to unmap only the poisoned
> > > PFN. This can have a major performance impact.
> > 
> > Is the performance impact really a concern in the event of failed
> > memory? 
> 
> Yes, something like the KVM S2 is very sensitive to page size for TLB
> performace.
> 
> > Does this happen enough to warrant this special case?
> 
> If you have a 100k sized cluster it happens constantly :\
> 
> > Surely it's not failing hardware that may cause performance impacts, so
> > is this triggered in some other way that I'm missing or a conversation
> > pointer?
> 
> It is the splitting of a pgd/pmd level into PTEs that gets mirrored
> into the S2 and then greatly increases the cost of table walks inside
> a guest. The HW caches are sized for 1G S2 PTEs, not 4k.

Ah, I see.  Seems like a worthy addition to the commit message?  I mean,
this is really a choice of throwing away memory for the benefit of tlb
performance.  Seems like a valid choice in your usecase but less so for
the average laptop.

Won't leaving the poisoned memory mapped cause migration issues?  Even
if the machine is migrated, my understanding is the poison follows
through checkpoint restore.

Thanks,
Liam