Re: [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches

[SeongJae Park <sj@kernel.org>]

On Tue, 12 Aug 2025 16:44:09 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> 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.

I like this conversion.

[...]
> 
> In order to execute this change, we introduce a new opaque type -
> mm_flags_t - which wraps a bitmap.

I have no strong opinion here, but I think coding-style.rst[1] has one?  To
quote,

    Please don't use things like ``vps_t``.
    It's a **mistake** to use typedef for structures and pointers. 

checkpatch.pl also complains similarly.

Again, I have no strong opinion, but I think adding a clarification about why
we use typedef despite of the documented recommendation here might be nice?

[...]
> For mm->flags initialisation on fork, we adjust the logic to ensure all
> bits are cleared correctly, and then adjust the existing intialisation

Nit.  s/intialisation/initialisation/ ?

[...]

[1] https://docs.kernel.org/process/coding-style.html#typedefs


Thanks,
SJ