From: Christoph Hellwig <hch@infradead.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC PATCH 0/4] make vmalloc gfp flags usage more apparent
Date: Mon, 3 Nov 2025 05:51:04 -0800 [thread overview]
Message-ID: <aQizSPAvNGmgpnxa@infradead.org> (raw)
In-Reply-To: <aQimnV815XIjV2JT@pc636>
On Mon, Nov 03, 2025 at 01:57:01PM +0100, Uladzislau Rezki wrote:
> > 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.
Yes, explicitly whitelisting the (component)flags supported seems like
a much more maintainable approach.
prev parent reply other threads:[~2025-11-03 13:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 16:43 [RFC PATCH 0/4] make vmalloc gfp flags usage more apparent Vishal Moola (Oracle)
2025-10-30 16:43 ` [RFC PATCH 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags Vishal Moola (Oracle)
2025-10-30 16:43 ` [RFC PATCH 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps Vishal Moola (Oracle)
2025-10-30 16:43 ` [RFC PATCH 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages() Vishal Moola (Oracle)
2025-10-30 16:43 ` [RFC PATCH 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block() Vishal Moola (Oracle)
2025-11-03 12:57 ` [RFC PATCH 0/4] make vmalloc gfp flags usage more apparent Uladzislau Rezki
2025-11-03 13:51 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQizSPAvNGmgpnxa@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=urezki@gmail.com \
--cc=vishal.moola@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.