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

Message-ID: <20251219152030.GA371266@nvidia.com>
Date: Fri, 19 Dec 2025 11:20:30 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Peter Xu <peterx@...hat.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 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!

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

Jason