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: <20251216144427.GF6079@nvidia.com>
Date: Tue, 16 Dec 2025 10:44:27 -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 Wed, Dec 10, 2025 at 03:23:02PM -0500, Peter Xu wrote:
> On Sun, Dec 07, 2025 at 12:21:32PM -0400, Jason Gunthorpe wrote:
> > On Thu, Dec 04, 2025 at 10:10:01AM -0500, Peter Xu wrote:
> > > Add one new file operation, get_mapping_order().  It can be used by file
> > > backends to report mapping order hints.
> > > 
> > > By default, Linux assumed we will map in PAGE_SIZE chunks.  With this hint,
> > > the driver can report the possibility of mapping chunks that are larger
> > > than PAGE_SIZE.  Then, the VA allocator will try to use that as alignment
> > > when allocating the VA ranges.
> > > 
> > > This is useful because when chunks to be mapped are larger than PAGE_SIZE,
> > > VA alignment matters and it needs to be aligned with the size of the chunk
> > > to be mapped.
> > > 
> > > Said that, no matter what is the alignment used for the VA allocation, the
> > > driver can still decide which size to map the chunks.  It is also not an
> > > issue if it keeps mapping in PAGE_SIZE.
> > > 
> > > get_mapping_order() is defined to take three parameters.  Besides the 1st
> > > parameter which will be the file object pointer, the 2nd + 3rd parameters
> > > being the pgoff + size of the mmap() request.  Its retval is defined as the
> > > order, which must be non-negative to enable the alignment.  When zero is
> > > returned, it should behave like when the hint is not provided, IOW,
> > > alignment will still be PAGE_SIZE.
> > 
> > This should explain how it works when the incoming pgoff is not
> > aligned..
> 
> Hmm, I thought the charm of this new proposal (based on suggestions of your
> v1 reviews) is to not need to worry on this..  Or maybe you meant I should
> add some doc comments in the commit message?

It can't be ignored, I don't think I ever said that. I said the driver
shouldn't have to worry about it, the core MM should deal with this.

> > I think for dpdk we want to support mapping around the MSI hole so
> > something like
> > 
> >  pgoff 0 -> 2M
> >  skip 4k
> >  2m + 4k -> 64M
> > 
> > Should setup the last VMA to align to 2M + 4k so the first PMD is
> > fragmented to 4k pages but the remaning part is 2M sized or better.
> > 
> > We just noticed a bug very similer to this in qemu around it's manual
> > alignment scheme where it would de-align things around the MSI window
> > and spoil the PMDs.
> 
> Right, IIUC this series should work all fine exactly as you said.

Are you sure? I did not see code doing this. The second mapping needs
to select a VA such that

  VA % 2M == 4k

And I don't see it doing that.

Jason