Re: [PATCH 01/10] mm: add bitmap mm->flags field

[David Hildenbrand <david@redhat.com>]

On 12.08.25 17:44, Lorenzo Stoakes wrote:
> We are currently in the bizarre situation where we are constrained on the
> number of flags we can set in an mm_struct based on whether this is a
> 32-bit or 64-bit kernel.
> 
> This is because mm->flags is an unsigned long field, which is 32-bits on a
> 32-bit system and 64-bits on a 64-bit system.
> 
> In order to keep things functional across both architectures, we do not
> permit mm flag bits to be set above flag 31 (i.e. the 32nd bit).
> 
> This is a silly situation, especially given how profligate we are in
> storing metadata in mm_struct, so let's convert mm->flags into a bitmap and
> allow ourselves as many bits as we like.
> 
> To keep things manageable, firstly we introduce the bitmap at a system word
> system as a new field mm->_flags, in union.
> 
> This means the new bitmap mm->_flags is bitwise exactly identical to the
> existing mm->flags field.
> 
> We have an opportunity to also introduce some type safety here, so let's
> wrap the mm flags field as a struct and declare it as an mm_flags_t typedef
> to keep it consistent with vm_flags_t for VMAs.
> 
> We make the internal field privately accessible, in order to force the use
> of helper functions so we can enforce that accesses are bitwise as
> required.
> 
> We therefore introduce accessors prefixed with mm_flags_*() for callers to
> use. We place the bit parameter first so as to match the parameter ordering
> of the *_bit() functions.
> 
> Having this temporary union arrangement allows us to incrementally swap
> over users of mm->flags patch-by-patch rather than having to do everything
> in one fell swoop.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---

Incl. fixup LGTM

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers

David / dhildenb