linux-kernel - Re: [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region

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] [day] [month] [year] [list]

Message-ID: <2190c4dc-ae84-4781-8e86-4b2ca99f2237@redhat.com>
Date: Wed, 24 Jul 2024 10:53:52 +0200
From: David Hildenbrand <david@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Peter Xu <peterx@...hat.com>, Yan Zhao <yan.y.zhao@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Alex Williamson <alex.williamson@...hat.com>,
 Al Viro <viro@...iv.linux.org.uk>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 "Kirill A . Shutemov" <kirill@...temov.name>, "x86@...nel.org"
 <x86@...nel.org>, "Tian, Kevin" <kevin.tian@...el.com>,
 Pei Li <peili.dev@...il.com>, David Wang <00107082@....com>,
 Bert Karwatzki <spasswolf@....de>,
 Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region

On 23.07.24 23:44, Jason Gunthorpe wrote:
> On Tue, Jul 23, 2024 at 11:36:51PM +0200, David Hildenbrand wrote:
>> I wonder if we could just let relevant users do the PAT handling manually:
>> I'm also not sure how many remap_pfn_range users end up triggering VM_PAT
>> code although they don't really have to (just because they happen to cover a
>> full VMA)?
>>
>> One nasty thing is fork(), I was wondering if relevant users really rely on
>> that or if we could force these VMAs to simply not get copied during fork.
>> During fork() we have to "duplicate" the reservation ...
> 
> I admit I barely understand what x86 uses this PAT stuff for -
> allowing WC mappings is part of it?

I'm confused by all of that, but I think yes :)

> 
> If yes, then RDMA would expect WC PFN MAP VMAs to copy their WCness
> during fork..

Okay, that answers that question: we have to support fork().

During fork() we call vm_ops->open when cloning the VMA. So the backend 
can realize when all users (VMAs, whatsoever) are gone to undo any 
registration. Maybe that's a path forward. But still no clue on details 
... one important step might be figuring out who exactly really relies 
on that VM_PAT handling.

-- 
Cheers,

David / dhildenb