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

["Vishal Moola (Oracle)" <vishal.moola@gmail.com>]

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?

Vishal Moola (Oracle) (4):
  mm/vmalloc: warn on invalid vmalloc gfp flags
  mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
  mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
  mm/vmalloc: cleanup gfp flag use in new_vmap_block()

 mm/vmalloc.c | 41 +++++++++++++++++++++++++++++++++--------
 1 file changed, 33 insertions(+), 8 deletions(-)

-- 
2.51.1