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

[Andrew Morton <akpm@linux-foundation.org>]

On Mon,  1 Jun 2026 14:50:15 +0200 Oscar Salvador <osalvador@suse.de> wrote:

> On x86, arch_get_unmapped_area{_topdown} set align_offset in order to avoid
> cache aliasing on I$ on AMD family 15h when 'align_va_addr' is enabled.
> Prior to commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags"),
> we did not have to worry about that because hugetlb specific code did not set
> align_offset, but above commit got rid of hugetlb specific code and started to route
> hugetlb mappings through the generic interface.
> Doing that has the effect of handling non-aligned hugetlb mappings to userspace,
> which is plain wrong.
> 
> So, skip setting align_offset if we are dealing with a hugetlb mapping.

Cool.

> Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags")
> Reported-by: Karsten Desler <kdesler@soohrt.org>
> Closes: https://lore.kernel.org/linux-mm/20260527143643.GO31091@soohrt.org/

Ah, there it is.  "the kernel later BUGs".  We'd prefer it not do that so I'll cc:stable.

Thanks for including the link.  And thanks Karsten for reporting and
testing.

> So, let me say two things:
> 1) Karsten tested below patch and reported it was working fine for him.
>    Did not stamp his Tested-by though, because it was not explicitly provided.

This often happens - testers (well, confirmers) don't formally add the
tag.  Often these people aren't regular kernel developers and simply
don't know the conventions.  But if I see that email, I'll add the
Tested-by: because that's what happened.

> 2) This is a hack, I know, and I should probably be flagellated for this but
>    since this is a regression, I went for the quick/easy-to-apply fix, so it can
>    be easily backported.

That works (the patch, not the flagellation).

>    Having said that, I already made my mind to fix this in a better way, which would
>    involve getting rid of hugetlb-specific code and do the masking off as we do for
>    THP, but for that I need to refactor the code and that would not be so easy
>    to backported. Just so you understand the reasoning behind.

Great, thanks, flagellation is excused.