On Tue, 12 Aug 2025 16:44:09 +0100 Lorenzo Stoakes [off-list ref] 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