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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251216185850.GH6079@nvidia.com>
Date: Tue, 16 Dec 2025 14:58:50 -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 Tue, Dec 16, 2025 at 12:36:13PM -0500, Peter Xu wrote:
> On Tue, Dec 16, 2025 at 01:19:44PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 16, 2025 at 10:42:39AM -0500, Peter Xu wrote:
> > > Also see __thp_get_unmapped_area() processed such pgoff, it allocates VA
> > > with len_pad (not len), and pad the retval at last.
> > > 
> > > Please let me know if it didn't work like it, then it might be a bug.
> > 
> > It should all be documented then in the kdoc for the new ops, in this
> > kind of language that the resulting VA flows from pgoff
> 
> IMHO that's one of the major benefits of this API, so that there's no need
> to mention impl details like this.

It needs to be clearly explained exactly how pgoff and the returned
order are related because it impacts how the drivers need to manage
their pgoff space.

> Here the point is, the driver should only care about the size of mapping,
> nothing else like how exactly the alignments will be calculated, and how
> that interacts with pgoff.  The kernel mm manages that. It's done exactly
> like what anon thp does already when len is pmd aligned.

The driver owns the pgoff number space, it has to care about how that
relates to the PTEs.

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

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ