Re: [RFC] Guidance on contributing to the MM subsystem and finding tasks

[Dev Jain <dev.jain@arm.com>]

On 09/11/25 5:07 pm, Swaraj Gaikwad wrote:
> Hi all,
> I’ve been following the MM subsystem for a while and have submitted a few
> small patches (mostly cleanups and basic fixes).I’d really like to become
> more involved and contribute to meaningful memory management work, but I’m
> having some trouble figuring out how to identify useful areas to work on.
>
> I have also looked at some TODOs in the mm/ code and submitted a patch for
> one of them. I’ve tried looking into syzbot reports as well, but often by
> the time I finish understanding the issue, someone else has already sent a
> fix. I’d still like to learn from such debugging efforts, but it would be
> great to find areas where I can make steady progress and contribute patches
> that are actually helpful.
>
> Could someone please share some guidance or suggestions on:
>    - How to find open problems or areas that need help in MM?
>    - Any advice for someone trying to move from small fixes toward more
>      substantial contributions?
>    - And if possible, could you suggest a few small or medium tasks that are
>      suitable for new contributors to the MM subsystem, the kind of things that
>      would be genuinely helpful and likely to be accepted?
>
> I’d really appreciate any pointers or direction.
> Thanks for your time and for maintaining this amazing subsystem.
>
> Best regards,
> Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
>
> Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>

Hello Swaraj!

I will recommend to first understand userspace interaction with the kernel - mm selftests
are a great way to understand that. Personally, I had started by looking at
tools/testing/selftests/mm/virtual_address_range.c. I played with how the VMAs are getting
created and displayed in /proc/self/maps, and when they get exhausted, what is the gap
between the VMAs (in fact, it took me some time to figure out that the ranges getting
displayed in /proc/self/maps are in fact exactly the VMAs!). This forced me to look
into mm/mmap.c (now also split into mm/vma.c) and try figuring out how we find a VMA and
map it. Eventually reading userspace code sent me looking for the corresponding kernel code.

>