From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Ye Liu <ye.liu@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Ye Liu <liuye@kylinos.cn>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC RFC PATCH] mm: convert VM flags from macros to enum
Date: Mon, 13 Oct 2025 12:33:27 +0100 [thread overview]
Message-ID: <d619784b-b967-4795-aad9-6e79d4191b83@lucifer.local> (raw)
In-Reply-To: <7ca0960f-9d1a-4ba4-b074-a6502578b82e@redhat.com>
On Mon, Oct 13, 2025 at 01:12:20PM +0200, David Hildenbrand wrote:
> On 13.10.25 13:04, Lorenzo Stoakes wrote:
> > On Sat, Oct 11, 2025 at 05:30:52PM +0800, Ye Liu wrote:
> > > From: Ye Liu <liuye@kylinos.cn>
> > >
> > > Hello MM maintainers and drgn community,
> > >
> > > This RFC proposes to convert VM_* flags from #define macros to enum
> > > vm_flags. The motivation comes from recent drgn development where we
> > > encountered difficulties in implementing VM flag parsing due to the
> > > current macro-based approach.
> >
> > This isn't going to work sorry, it's not valid to have flag values as an enum
>
> I don't follow, can you elaborate? IIRC, the compiler will use an integer
> type to back the enum that will fit all values.
switch (flags) {
case VAL1:
case VAL2:
etc.
}
Is broken (compiler will say you cover all cases when you don't...)
An enum implies independent values that exhaustively describe all state, however
these flag values are not that - they're intended to be bit fields.
Also we specifically have the vm_flags_t whose type VMA flags should be, right
now it's an integer type - unsigned long - after my changes it'll be an opaque
type that'll blow up expectations of what this change does altogether.
>
> > (they're distinct) and also - importantly - I'm going to be making significant
> > changes to VMA flags soon (to allow us to have arbitrary number of VMA flags on
> > _all_ architectures as recently done with my series doing something similar with
> > mm flags).
>
> I guess this patch should not really make a big difference regarding your
> upcoming plans?
I don't think it's really useful to do this in any way, and as I said, my change
will allow these tools to have a much better solution, which is to reference the
- actually valid as an enum - bit values.
>
> I do hate the enum stuff to make these tools happy, though :)
Yes, if the tools can't handle standard kernel conventions, the problem is not
in the kernel :)
>
> --
> Cheers
>
> David / dhildenb
>
If it makes life easier - I can prioritise doing the 'make VMA flag bit numbers
an enum' patch as an early part of the upcoming series (and in fact likely to be
multiple series given the scope).
Cheers, Lorenzo
next prev parent reply other threads:[~2025-10-13 11:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 9:30 Ye Liu
2025-10-13 11:04 ` Lorenzo Stoakes
2025-10-13 11:12 ` David Hildenbrand
2025-10-13 11:33 ` Lorenzo Stoakes [this message]
2025-10-13 12:31 ` David Hildenbrand
2025-10-13 12:33 ` David Hildenbrand
2025-10-13 12:57 ` Lorenzo Stoakes
2025-10-13 13:07 ` Vlastimil Babka
2025-10-13 13:19 ` Lorenzo Stoakes
2025-10-13 13:22 ` David Hildenbrand
2025-10-14 8:26 ` Ye Liu
2025-10-13 13:11 ` David Hildenbrand
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=d619784b-b967-4795-aad9-6e79d4191b83@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuye@kylinos.cn \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=ye.liu@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox