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

Message-ID: <f48c1a91-8ed1-447d-93ad-449f28753c5c@redhat.com>
Date: Tue, 23 Jul 2024 23:36:51 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: 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>,
 Jason Gunthorpe <jgg@...dia.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 22:27, Peter Xu wrote:
> On Mon, Jul 22, 2024 at 11:17:57AM +0200, David Hildenbrand wrote:
>> What we do have is a single VMA, whereby within that VMA we place various
>> different PFN ranges. (randomly looking at drivers/video/fbdev/smscufx.c)
>>
>> These wouldn't have triggered VM_PAT code.
> 
> Right, it looks like VM_PAT is only applying to a whole-vma mapping, even
> though I don't know how that was designed..
> 
> I wished vma->vm_pgoff was for storing the base PFN for VM_SHARED too: now
> it only works like that for CoW mappings in remap_pfn_range_notrack(), then
> it looks like VM_SHARED users of remap_pfn_range() can reuse vm_pgoff, and
> I think VFIO does reuse it at least..
> 
> I am a bit confused on why Linux made that different for VM_SHARED,
> probably since b3b9c2932c32 ("mm, x86, pat: rework linear pfn-mmap
> tracking").  I wished vm_pgoff was always used for internal maintenance
> (even for VM_SHARED) so this issue should be easier to solve.
> 
> Maybe we can still re-define vm_pgoff for VM_SHARED pfnmaps? The caller
> should always be able to encode information in vm_private_data anyway.
> But I think that might break OOT users..

Yeah, I played with this idea when trying to remove the page table walk 
and storing it in the VMA, avoiding consuming more memory. The vm_pgoff 
usage for VM_PFNMAP mappings that I could spot looked nasty enough for 
me to not dare trying.

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 ...

No real solution yet :/ Getting id of the page table walk is possible (I 
can try digging up the patch I was able to come up with), but it feels 
like the wrong approach.

The owner of the VMA should have that information ...

-- 
Cheers,

David / dhildenb