Home

Linux kernel mentorship experience

Written in November 2025 by Hanne-Lotta

I was in the Linux kernel Bug Fixing Summer 2025 mentorship program and here's how it went.

I found out about the program through LinkedIn. I sent an application, and completed the prerequisite tasks. To my surprise, I was accepted. I received an invitation to weekly Zoom meetings held by Shuah Khan, and a Discord channel link.

The application process took about a month, during which I learned to build and boot the Linux kernel, about the development process, different source trees, various mailing lists, and how to submit patches using git. The tasks were simple enough but took time to complete, especially when I hadn't any setup ready before starting. I repurposed an unused laptop by installing Debian on it and setting up the development environment.

Free form

The mentorship program is very free form, as there are no weekly assignments, no mandatory attendance — it's an opportunity to ask questions and receive guidance. This is completely up to personal interest and willingness to explore the kernel code.

The goal is to get five patches accepted to the Linux kernel.

Shuah showed basic tools during the weekly Zoom meetings, and answered questions. In the first weeks there were so many questions that there was no time to answer them all. As the weeks went by, there was more time for individual guidance on various areas, like debugging a specific syzbot bug, or backporting.

David Hunter is also a mentor in the program, and he is helping with answering questions, patches and everything.

I attended the weekly Zoom meetings to ask the questions I had accumulated during the week. It gave me motivation to keep exploring every week, so that I would have something to ask. Some weeks I didn't make much progress, but even then it was encouraging to hear that other mentees had been struggling with fixing bugs as well, and how it was completely normal to feel overwhelmed.

Finding stuff to work on

I learned quickly how to reproduce bugs reported by syzbot, but I found it difficult to understand and fix them.

I installed static tools to analyze the kernel's C code, but for some reason I didn't end up trying to fix code style warnings.

I made one small refactoring to the Linux kernel's USB core code — to use sysfs_emit_at() instead of scnprintf() when showing dynamic IDs, to prevent buffer overruns. This type of refactoring was suggested by Shuah. The patch was my first accepted change to kernel code that wasn't about fixing typos in the documentation.

After that I started to look into backporting.

Backporting

Stable kernel versions are maintained by backporting bug fixes to them from the mainline kernel. Not all of the bug fixing patches apply to older kernel versions without version conflicts, and this is where some manual work is required.

It turns out backporting is a great way to start contributing. I get to read other people's code, and learn about the kernel while resolving version conflicts. Even though I will not be the author of the patch, the most important thing is to get the fix backported.

I did backports for the wifi subsystem during this program.

I have instructions for backporting here.

I was greeted with a screen of eight tuxes at one point, when testing stable kernel configurations.

Summary of my experience

I am amazed that this type of mentoring exists, and it's free of charge. I am very lucky to have found it.

The enthusiasm of fellow mentees is contagious. I've learned from others' patches and interactions in the mailing list. There is a lot of activity in the Discord channel, which feels like a low threshold place to ask questions. Thanks to all of you!

Shuah is awesome to be organizing this, especially with everything else she is doing. It's meaningful and useful. Thank you Shuah! And thank you David.

I dream of being a kernel maintainer one day. Yes, I realize how unlikely it is and I've only touched perhaps 0.02 % of the knowledge required to do it. At any rate, this mentorship program has gotten me started.

I can recommend this type of mentorship program to anyone interested in Linux kernel development. You'll learn the basics, and find out if kernel development interests you in the long term. What I find most valuable still, is that you get a feel of the supportive open source community.

Tips

Here are some tips, if you happen to be a mentee in this program.

• For Linux kernel development, I recommend installing your preferred Linux distro on a computer instead of utilizing VMs or dual boot. It's just simpler and more likely to work, if you can afford it.
• Read the docs, the mailing lists, and watch the recommended LF mentorship videos. Keep reading the docs. If you only do one of these things, it should be reading the docs.
• When coding, test the kernel code by executing the paths you've changed. Use debugging tools, tracing, tests, or even print statements. If you think this is self evident that people do this, you would be surprised.
• When creating a patch or patch series from git commits, triple check everything, and send the patch(es) to yourself first. It's better to iterate the formatting, title prefixing, version logging with notes, wording, etc privately than in the public mailing lists.
• It helps to keep a personal log or text file of commands, links, stuff that is repeated a lot. I keep a notes file at hand so that I remember to use ./scripts/checkpatch.pl and ./scripts/get_maintainers.pl, and then about the various git commands, such as git format-patch or how to add git notes. Especially in the beginning this is super useful.