Re: [PATCH 4/8] arch/s390: Stop special-casing hugetlb mappings in arch_get_unmapped_area

[Gerald Schaefer <gerald.schaefer@linux.ibm.com>]

On Sat,  6 Jun 2026 05:49:59 +0200
Oscar Salvador <osalvador@suse.de> wrote:

> arch_get_unmapped_area* sets info.align_mask to make room for extra alignment,
> so that is added on top of the length we request in unmapped_area{_topdown}.
> hugetlb_get_unmapped_area() already adds this extra padding in the 'len'
> parameter, and it also masks off the address it gets to properly align it to
> the huge_page_size we are using.
> 
> So, stop special-casing hugetlb in arch_get_unmapped_area* functions.
> 
> Also, there is no need to worry about align_offset because that will be
> masked off back in hugetlb_get_unmapped_area().
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> ---
>  arch/s390/mm/mmap.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)

With regard to the Critical finding for s390 in Sashiko review in
https://sashiko.dev/#/patchset/20260606035003.529685-1-osalvador@suse.de

Yes, I think crst_table_upgrade() could be skipped "If the original length
fits right below TASK_SIZE, but the inflated length pushes addr + len over
TASK_SIZE".

But subsequent page faults should then generate an ASCE-type exception,
killing the user space program, and not alias with lower virtual addresses
causing memory corruption.

Still, I wonder if we want an extra check for "addr + (inflated) len > TASK_SIZE"
in check_asce_limit(), or somewhere else.

This "inflated length" approach also seems to have other subtle impact for
other archs, according to Sashiko. Possibly resulting in failed mappings for
valid addresses and ranges. So some extra checking or retry logic might be
needed anyway.