linux-kernel - Re: [PATCH 3/5] mm: Rename __thp_get_unmapped_area to mm_get_unmapped_area

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: <aExueZPrt7z-jRdc@x1.local>
Date: Fri, 13 Jun 2025 14:31:21 -0400
From: Peter Xu <peterx@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, kvm@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alex Williamson <alex.williamson@...hat.com>,
	Zi Yan <ziy@...dia.com>, Alex Mastro <amastro@...com>,
	David Hildenbrand <david@...hat.com>,
	Nico Pache <npache@...hat.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Ryan Roberts <ryan.roberts@....com>, Dev Jain <dev.jain@....com>,
	Barry Song <baohua@...nel.org>
Subject: Re: [PATCH 3/5] mm: Rename __thp_get_unmapped_area to
 mm_get_unmapped_area_aligned

On Fri, Jun 13, 2025 at 01:00:20PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 13, 2025 at 11:13:58AM -0400, Peter Xu wrote:
> > > I didn't intuitively guess how it works or why there are two
> > > length/size arguments. It seems to have an exciting return code as
> > > well.
> > > 
> > > I suppose size is the alignment target? Maybe rename the parameter too?
> > 
> > Yes, when the kdoc is there it'll be more obvious.  So far "size" is ok to
> > me, but if you have better suggestion please shoot - whatever I came up
> > with so far seems to be too long, and maybe not necessary when kdoc will be
> > available too.
> 
> I would call it align not size

Sure thing.

> 
> > > For the purposes of VFIO do we need to be careful about math overflow here:
> > > 
> > > 	loff_t off_end = off + len;
> > > 	loff_t off_align = round_up(off, size);
> > > 
> > > ?
> > 
> > IIUC the 1st one was covered by the latter check here:
> > 
> >         (off + len_pad) < off
> > 
> > Indeed I didn't see what makes sure the 2nd won't overflow.
> 
> I'm not sure the < tests are safe in this modern world. I would use
> the overflow helpers directly and remove the < overflow checks.

Good to learn the traps, and I also wasn't aware of the helpers.  I'll
switch to that, thanks!

> 
> > +/**
> > + * mm_get_unmapped_area_aligned - Allocate an aligned virtual address
> > + * @filp: file target of the mmap() request
> > + * @addr: hint address from mmap() request
> > + * @len: len of the mmap() request
> > + * @off: file offset of the mmap() request
> > + * @flags: flags of the mmap() request
> > + * @size: the size of alignment the caller requests
> 
> Just "the alignment the caller requests"

Sure.

> 
> > + * @vm_flags: the vm_flags passed from get_unmapped_area() caller
> > + *
> > + * This function should normally be used by a driver's specific
> > + * get_unmapped_area() handler to provide a properly aligned virtual
> > + * address for a specific mmap() request.  The caller should pass in most
> > + * of the parameters from the get_unmapped_area() request, but properly
> > + * specify @size as the alignment needed.
> 
>  .. "The function willl try to return a VMA starting address such that
>  ret % size == 0"

This is not true though when pgoff isn't aligned..

For example, an allocation with (len=32M, size=2M, pgoff=1M) will return an
address that is N*2M+1M, so that starting from pgoff=2M it'll be completely
aligned.  In this case the returned mmap() address must not be aligned to
make it happen, and the range within pgoff=1M-2M will be mapped with 4K.

-- 
Peter Xu