linux-kernel - Re: [RFC RFC PATCH] mm: convert VM flags from macros to enum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1638fe08-b0f4-4dd0-99f9-366796b74ee2@redhat.com>
Date: Mon, 13 Oct 2025 15:22:17 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>
Cc: Ye Liu <ye.liu@...ux.dev>, Andrew Morton <akpm@...ux-foundation.org>,
 Ye Liu <liuye@...inos.cn>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Mike Rapoport <rppt@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>,
 Michal Hocko <mhocko@...e.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC RFC PATCH] mm: convert VM flags from macros to enum

On 13.10.25 15:19, Lorenzo Stoakes wrote:
> On Mon, Oct 13, 2025 at 03:07:18PM +0200, Vlastimil Babka wrote:
>> On 10/13/25 14:57, Lorenzo Stoakes wrote:
>>> FOLL_* flags are an anonymous enum, enum fault_flag is not used as a type
>>> anywhere, nor is vm_fault_reason. So those are both kinda weird as to why we
>>> even name the type (they're in effect anonymous).
>>>
>>> But also 'we do X in the kernel' doesn't mean doing X is right :)
>>
>> I think the example to follow could be GFP flags. Nowadays there's an enum
>> below it, and a layer that adds (__force gfp_t), so you could do similar
>> thing with vm_flags_t.
>>
>> However I'm not sure how compatible is that with Lorenzo's plans.
> 
> That's defining bit values in an anonymous enum so isn't really comparable.
> 
> But what it's doing, ultimately, in broad terms (other than the opaque bitmap
> type I'll be using for VMA flags) is what my changes will do.
> 
> And yeah, trying to do duplicate that is not really a good use of time and will
> conflict with my work.
> 
> Overall I think this change is generally unnecessary given that I'm about to
> radically alter how VMA flags are implemented, and actually will cause me
> problems.
> 
> But as I said before, I'm happy to prioritise the change that specifies the
> flags based on the bit numbers, I actually have it ready more-or-less.

Yeah, let's do that if you expect to have it ready soonish.

-- 
Cheers

David / dhildenb