Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order()

[Jason Gunthorpe]

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