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

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

[Swaraj Gaikwad]

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>

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

[Dev Jain]

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.

>

Re: Guidance on contributing to MM subsystem

[Swaraj Gaikwad]

Hi Dev,
Thank you so much for your reply and for sharing your experience.
I do have some basic understanding of how parts of the MM subsystem work,
but I’m still struggling with how to find meaningful issues or tasks to work
on. For example, I’ve been trying to explore various parts of the code and
read through documentation to get a better grasp of how things fit together.

In other open-source projects, like on GitHub, there’s usually an “Issues”
section where contributors can easily find bugs or tasks to work on. In the
kernel, should I mainly focus on exploring TODOs, adding selftests, or
improving documentation (especially for new or less-documented parts)? I
also believe branches like mm-unstable and mm-new might have ongoing issues
or regressions, but how do developers usually find or detect them? Would
simply building these branches expose such problems through compiler errors,
or should I try building with different configurations (for example, using
defconfig and other configs) to uncover potential issues?

Even though I’m beginning to understand how different parts of the subsystem
interact, I’m not sure how developers usually identify new bugs or feature
ideas to work on. Once I understand the code flow better, how can I
effectively find such issues or areas where help is actually needed?

Thanks again for your time and guidance!

Best regards,
Swaraj Gaikwad

Re: Guidance on contributing to MM subsystem

[Dev Jain]

On 09/11/25 7:44 pm, Swaraj Gaikwad wrote:
> Hi Dev,
> Thank you so much for your reply and for sharing your experience.
> I do have some basic understanding of how parts of the MM subsystem work,
> but I’m still struggling with how to find meaningful issues or tasks to work
> on. For example, I’ve been trying to explore various parts of the code and
> read through documentation to get a better grasp of how things fit together.
>
> In other open-source projects, like on GitHub, there’s usually an “Issues”
> section where contributors can easily find bugs or tasks to work on. In the
> kernel, should I mainly focus on exploring TODOs, adding selftests, or
> improving documentation (especially for new or less-documented parts)? I
> also believe branches like mm-unstable and mm-new might have ongoing issues
> or regressions, but how do developers usually find or detect them? Would
> simply building these branches expose such problems through compiler errors,
> or should I try building with different configurations (for example, using
> defconfig and other configs) to uncover potential issues?

Yes this may be an option, to pick up mm-new and build it with
various configurations which are not extensively tested, and stress testing
with mm-selftests/mm-tests by Mel Gorman, etc. I had my first bug report
by just randomly testing CONFIG_LPA2 on arm64:

https://lore.kernel.org/all/20240415094003.1812018-1-anshuman.khandual@arm.com/

>
> Even though I’m beginning to understand how different parts of the subsystem
> interact, I’m not sure how developers usually identify new bugs or feature
> ideas to work on. Once I understand the code flow better, how can I
> effectively find such issues or areas where help is actually needed?

I would say to not pressurize yourself to find tasks, but focussing on
learning the code. Try to review patches - that will increase your
understanding of the code, and it will make you sit in the shoes
of the poster and think "what made them think of this work?". Leaving
aside very big functionality changes, most of the patches, in my experience,
are found by extreme understanding of the code and while reading it,
having an aha moment of "this looks stupid", "this is a bug" or
"surely there is a better way of doing this".

I'll give some examples.

https://lore.kernel.org/all/20251017160251.96717-1-dev.jain@arm.com/

I figured this out when reading mprotect code and observed that we are
doing an unconditional TLB flush (via mmu gather) for arm64 - pte_needs_flush()
was not implemented there. It is obvious (if you know about pte protections)
that we don't need to do that for a transition from PROT_NONE to any other.

https://lore.kernel.org/all/20250610035043.75448-1-dev.jain@arm.com/
https://lore.kernel.org/all/20250718090244.21092-1-dev.jain@arm.com/

On arm64, ptep_get() becomes costly due to collection of a/d bits for cont mappings;
I literally went around the codebase and checked whether we can batch process ptes
to avoid this cost.

https://lore.kernel.org/all/20250908075028.38431-1-dev.jain@arm.com/

I observed that khugepaged is operating only on writable regions. This didn't make
any sense to me - I scanned the history and couldn't prove that this is of any
use, hence posted on the list, and the community agreed (and the performance numbers
agreed too, as described in the cover letter).

One more interesting example -
https://lore.kernel.org/all/13945f06-f862-4f80-904a-f2a4ccff3e4b@redhat.com/

While reviewing an unrelated patch, David Hildenbrand reads the code and spots a problem
with the existing code, which was brought in by my patch, and I had to fix it in this:
https://lore.kernel.org/all/20251028063952.90313-1-dev.jain@arm.com/


As you can see, we "observed" all these things. The probability of making an observation
is directly proportional to the knowledge of the codebase (as is true with any other
skill). Which leads me to the conclusion - focussing on finding a task may be counter-productive.
Reviewing patches will force you to read the code and find potential problems with it.

>
> Thanks again for your time and guidance!
>
> Best regards,
> Swaraj Gaikwad

Re: Guidance on contributing to MM subsystem

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

On Sun, Nov 09, 2025 at 02:14:50PM +0000, Swaraj Gaikwad wrote:
> Hi Dev,
> Thank you so much for your reply and for sharing your experience.
> I do have some basic understanding of how parts of the MM subsystem work,
> but I’m still struggling with how to find meaningful issues or tasks to work
> on. For example, I’ve been trying to explore various parts of the code and
> read through documentation to get a better grasp of how things fit together.
> 
> In other open-source projects, like on GitHub, there’s usually an “Issues”
> section where contributors can easily find bugs or tasks to work on. In the
> kernel, should I mainly focus on exploring TODOs, adding selftests, or
> improving documentation (especially for new or less-documented parts)? I
> also believe branches like mm-unstable and mm-new might have ongoing issues
> or regressions, but how do developers usually find or detect them? Would
> simply building these branches expose such problems through compiler errors,
> or should I try building with different configurations (for example, using
> defconfig and other configs) to uncover potential issues?
> 
> Even though I’m beginning to understand how different parts of the subsystem
> interact, I’m not sure how developers usually identify new bugs or feature
> ideas to work on. Once I understand the code flow better, how can I
> effectively find such issues or areas where help is actually needed?

I can only speak for the documentation subsystem as I'm regular there.

For docs, I'm usually watching linux-next mailing list and looking for new
build warnings report there. If the report says htmldocs AND the warnings are
emitted from Sphinx (look for [docutils] like [1]), I reproduce them locally
(make sure to set up the environment per Documentation/doc-guide/sphinx.rst)
and fix them (in that case, I submit [2]). In absence of aforementioned, I
build htmldocs then wandered through its resulting output to see what
formatting improvements I can make and submit (e.g. [3], [4], and [5]).

Thanks.

[1]: https://lore.kernel.org/linux-next/20251106143925.578e411b@canb.auug.org.au/
[2]: https://lore.kernel.org/linux-doc/20251107081300.13033-2-bagasdotme@gmail.com/
[3]: https://lore.kernel.org/linux-doc/20251103093817.52764-2-bagasdotme@gmail.com/
[4]: https://lore.kernel.org/linux-doc/20251017064525.28836-2-bagasdotme@gmail.com/
[5]: https://lore.kernel.org/linux-doc/20251013095630.34235-2-bagasdotme@gmail.com/

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]