linux-kernel - Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping

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: <aUV0_TH56QeZIBXU@x1.local>
Date: Fri, 19 Dec 2025 10:53:33 -0500
From: Peter Xu <peterx@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: kvm@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Nico Pache <npache@...hat.com>, Zi Yan <ziy@...dia.com>,
	Alex Mastro <amastro@...com>, David Hildenbrand <david@...hat.com>,
	Alex Williamson <alex@...zbot.org>, Zhi Wang <zhiw@...dia.com>,
	David Laight <david.laight.linux@...il.com>,
	Yi Liu <yi.l.liu@...el.com>, Ankit Agrawal <ankita@...dia.com>,
	Kevin Tian <kevin.tian@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order()

On Fri, Dec 19, 2025 at 11:20:30AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 19, 2025 at 10:13:02AM -0500, Peter Xu wrote:
> > On Fri, Dec 19, 2025 at 10:59:57AM -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 16, 2025 at 02:44:29PM -0500, Peter Xu wrote:
> > > > > > Or maybe I misunderstood what you're suggesting to document?  If so, please
> > > > > > let me know; some example would be greatly helpful.
> > > > > 
> > > > > Just document the 'VA % order = pgoff % order' equation in the kdoc
> > > > > for the new op.
> > > > 
> > > > When it's "related to PTEs", it's talking about (2) above, so that's really
> > > > what I want to avoid mentioning.
> > > 
> > > You can't avoid it. Drivers must ensure that
> > > 
> > >   pgoff % order == physical % order
> > > 
> > > And that is something only drivers can do by knowing about this
> > > requirement.
> > 
> > This is a current limitation that above must be guaranteed, there's not
> > much the driver can do, IMHO.
> 
> There is alot the driver can do! The driver decides on the pgoff
> values it is using, it needs to keep the above in mind when it builds
> its pgoff number space!

Yeah, if so, it's reassuring. :)

> 
> > If you could remember, that's the only reason why I used to suggest (while
> > we were discussing this in v1) to make it *pgoff instead of pgoff, so that
> > drivers can change *pgoff to make it relevant to HPA.
> 
> What? That's nonsense. The pgoff space is assigned by the driver and
> needs to remain a fixed relationship to the underlying phys the driver
> is mapping in. It shouldn't be changing pgoff during mmap!

I meant, return *pgoff as a hint, not changing the pgoff to be used.. Only
changing the pgoff (as an integer) to be used in the VA calculations.

Thanks for sharing above information to ease my mind, if drivers are all
smart enough (I'll trust you more than myself on driver knowledges!) I
think we're all good..

-- 
Peter Xu