Re: [PATCH] arch,x86: Skip setting align_offset for hugetlb mappings

[Dave Hansen]

On 6/4/26 07:51, Oscar Salvador (SUSE) wrote:
> On Mon, Jun 01, 2026 at 01:25:12PM -0700, Dave Hansen wrote:
>> Oscar, even if the real fix involves a couple of patches, can we please
>> see that, first? Then, we can go back and make an informed decision
>> about hacks versus proper fixes.
> Fix sits here [1].
> It is quite straightforward, is arch-agnostic and I can confirm it fixes
> the AMD regression.
> It is part of a 8-patch series [2] (#1 is the fix and follow up are
> cleanups).

So it does appear that the x86 workaround wasn't the best direction.

That patch looks fine. I find it a bit hard to parse. I'd probably say
something more along the lines of:

	/*
	 * hugetlb mappings need to be huge page aligned.
	 * mm_get_unmapped_area_vmflags() only gives back PAGE_SIZE
	 * aligned areas.
	 *
	 * Extend the requested unmapped area for the worse case
	 * scenario: the address comes back and needs to be aligned
	 * up by one small page short of a large page.
	 */
	len += huge_page_size(h) - PAGE_SIZE;

Also, wouldn't it be more clear to just talk about the length in terms
of page sizes, not masks?

Also, do you even need this if()?

	if (addr0 & ~huge_page_mask(h))

So the code looks like this:
	
	pgoff = 0;
	addr0 = mm_get_unmapped_area_vmflags(file, addr0,...
	/* Align the address to the next huge_page_size boundary */
	addr0 = ALIGN(addr0, huge_page_size(h));

If it's aligned, it won't do anything.

But I'm 100% ok with the approach. I *believe* the code you have is OK,
although I'm not feeling super confident that I've read the mask
calculations correctly.

So while I'd like some improvements, I'm OK with this:

Acked-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>