[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251121094405.40628-1-vishal.moola@gmail.com>
Date: Fri, 21 Nov 2025 01:44:01 -0800
From: "Vishal Moola (Oracle)" <vishal.moola@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Uladzislau Rezki <urezki@...il.com>,
Christoph Hellwig <hch@...radead.org>,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
"Vishal Moola (Oracle)" <vishal.moola@...il.com>
Subject: [PATCH v4 0/4] make vmalloc gfp flags usage more apparent
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 hard to read gfp code.
---
Based on current mm-new.
v3 -> v4:
- Add __GFP_NOLOCKDEP to the list of supported flags[1]
- Replace WARN() with WARN_ONCE() to ratelimit warnings[2]
- Collect some tags
Previous iterations are linked through v3[3].
[1] https://lore.kernel.org/linux-mm/20251121072945.GA30438@lst.de/T/#m7cd63a45d0cde563158ddde5ea54e46715e34381
[2] https://lore.kernel.org/mm-commits/20251119164452.0f763efbb282f71438a2964a@linux-foundation.org/T/#t
[3] https://lore.kernel.org/linux-mm/20251117173530.43293-1-vishal.moola@gmail.com/
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 | 50 ++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 42 insertions(+), 8 deletions(-)
--
2.51.1
Powered by blists - more mailing lists