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:

quoted

quoted

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.

quoted

quoted

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!

quoted

+/**
+ * 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.

quoted

+ * @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