Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

Michal Hocko
2024-08-26T07:52:47Z

On Fri 23-08-24 18:42:47, Uladzislau Rezki wrote:
[...]
> @@ -3666,7 +3655,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> set_vm_area_page_order(area, page_shift - PAGE_SHIFT);
> page_order = vm_area_page_order(area);
>
> - area->nr_pages = vm_area_alloc_pages(gfp_mask | __GFP_NOWARN,
> + /*
> + * Higher order nofail allocations are really expensive and
> + * potentially dangerous (pre-mature OOM, disruptive reclaim
> + * and compaction etc.
> + *
> + * Please note, the __vmalloc_node_range_noprof() falls-back
> + * to order-0 pages if high-order attempt has been unsuccessful.
> + */
> + area->nr_pages = vm_area_alloc_pages(page_order ?
> + gfp_mask &= ~__GFP_NOFAIL : gfp_mask | __GFP_NOWARN,
> node, page_order, nr_small_pages, area->pages);
>
> atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
> <snip>
>
> Is that aligned with your wish?

I am not a great fan of modifying gfp_mask inside the ternary operator
like that. It makes the code harder to read. Is there any actual reason
to simply drop GFP_NOFAIL unconditionally and rely do the NOFAIL
handling for all orders at the same place?

Not that I care about this much TBH. It is an improvement to drop all
the NOFAIL specifics from vm_area_alloc_pages.

--
Michal Hocko
SUSE Labs