[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb17f29e-b45a-4275-ab2b-1443d909d944@arm.com>
Date: Sun, 9 Nov 2025 13:13:47 +0530
From: Dev Jain <dev.jain@....com>
To: Swaraj Gaikwad <swarajgaikwad1925@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Guidance on contributing to the MM subsystem and finding
tasks
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@...il.com>
>
> Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@...il.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.
>
Powered by blists - more mailing lists