Re: [RFC PATCH 0/4] make vmalloc gfp flags usage more apparent

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Oct 30, 2025 at 09:43:26AM -0700, Vishal Moola (Oracle) wrote:
> We should do a better job at enforcing gfp flags for vmalloc. Right now, we
> have a kernel-doc for __vmalloc_node_range(), and hope callers pass in
> supported flags. If a caller were to pass in an unsupported flag, we may
> BUG, silently clear it, or completely ignore it.
> 
> If we are more proactive about enforcing gfp flags, we can making sure
> callers know when they may be asking for unsupported behavior.
> 
> This patchset lets vmalloc control the incoming gfp flags, and cleans up
> some confusing gfp code.
> 
> ----------------
> Based on mm-new
> 
> I did some digging and am not entirely sure what flags vmalloc does NOT
> support. Is a better idea is to have explicitly supported flags and drop
> all others?
> 
> __GFP_COMP is an obvious one due to a BUG call in split_page().
> ~GFP_BITS_MASK is also obvious.
> 
> Then I started following the kernel doc and added NORETRY and
> RETRY_MAYFAIL, and after forking a couple hundred times, it turns out some
> per-cpu allocations pass in the NORETRY flag right now.
> 
> Does anyone have a handy-dandy list of supported/unsupported vmalloc flags
> that we should reject/clear? Ulad?
> 
We recently have added GFP_ATOMIC, GFP_NOWAIT support. Both are handled
based on gfpflags_allow_blocking() checking:

<snip>
* Supported GFP classes: %GFP_KERNEL, %GFP_ATOMIC, %GFP_NOWAIT,
 * %GFP_NOFS and %GFP_NOIO. Zone modifiers are not supported.
 * Please note %GFP_ATOMIC and %GFP_NOWAIT are supported only
 * by __vmalloc().
<snip>

>
> I did some digging and am not entirely sure what flags vmalloc does NOT
> support. Is a better idea is to have explicitly supported flags and drop
> all others?
>
Maybe we should look at it vice versa. Focus on supported flags. In the
slab there is an adjust function which modifies the gfp and emits the warning
if passed GFP is part of buggy mask.

--
Uladzislau Rezki