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

Peter Xu
2025-12-19T15:53:38Z

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