**My Journey Through the Linux Kernel Bug-Fix Mentorship Program**

Entering the Linux Kernel Bug-Fix Mentorship Program has been one of the most transformative experiences of my engineering career so far. As an embedded systems engineer who had always admired the Linux kernel from a distance, I never imagined I would eventually contribute to it. This mentorship took me from curiosity, to hands-on debugging, to writing real patches, working with reviewers and maintainers, and understanding how a huge open-source project operates.

This post captures my journey from the application stage to the final report: the challenges, lessons, and the growth I experienced.

🌱 **The Beginning: Application Phase**

Before applying, my knowledge of Linux development was mostly theoretical. I had read books and probably followed a few discussions, but I had never done any real kernel work.
I saw the the mentorship advert via LinkedIn and I didn't hesistate to apply.

The application process required completing several tasks:

- Building and booting the kernel

- Writing a kernel module

- Completing A beginner's guide to Linux Kernel Developement course

- Adding command-line arguments to a module

- Documentation updates

- Causing a kernel panic intentionally

- Researching PCI and USB devices

- Adding extra kernel version

- Decoding stack traces

- Learning how kselftest works

- etc.

These tasks alone felt like a mini-mentorship. They showed me how structured the kernel world is, and how much detail matters. I submitted a couple of patches during this stage, and even though they were not reviewed or accepted, I later understood why once I progressed in the program.

Submitting the application felt like taking a bold step toward something I had always wanted to try but never had the chance to.

📥 **Getting Accepted: A New Chapter Begins**

The acceptance email felt unreal. I was excited and cautious at the same time, knowing I was stepping into one of the most respected engineering communities in the world.

Right from the beginning, it was clear that the mentorship wasn’t only about fixing bugs; it was about learning the workflow, understanding tools, communicating through mailing lists, writing good patches, debugging, documenting, and testing properly.

💻 **Setting Up: Getting My Hands Dirty**

I had already done most of the environment setup during the application phase thanks to “The beginner’s guide to Linux kernel development” course. I used a Windows system for the mentorship, so I worked inside an Ubuntu virtual machine.

My setup and learning during this stage included:

- Configuring git properly

- Learning git send-email, git format-patch, and the mailing-list workflow

- Building the kernel from source

- Understanding .config files and Kconfig options

- Exploring syzbot and selftests

- Following kernel documentation and coding style

I also studied Pro Git, which improved my confidence with advanced git commands like rebasing, amending, splitting commits, handling patch series, etc. These skills now help me even in my full-time firmware / embedded software job.

🐞 **Working With Syzbot Bugs: Early Challenges**

One of the main parts of the mentorship involved investigating bugs reported by syzbot — the automated fuzzing system for the Linux kernel.

I tried working on three syzbot bugs, but eventually lost track of them. The only remaining files I had were the .config and disk images.

Some challenges I faced:

1. Memory limitations

Building kernels using syzbot-provided configs sometimes completely consumed my RAM, causing the build to crash.

2. Difficulty reproducing the bugs

Eventually, I was able to build and reproduced one of the bugs at least once, but I wasn't able to afterwards. Even though I couldn’t continue with those bugs, the experience taught me how syzbot works, what reproducer environments look like, and how kernel debugging is approached.

📨 **Submitting My First Patches**

My very first patch was actually submitted during the application stage. Seeing my name appear on LKML for the first time was exciting.

My first accepted patch came few weeks after the mentorship started. It was related to a FIXME that had been sitting in the code for many years. After improving the patch based on feedback (basically completely removing the FIXME), it was accepted. That moment felt incredible.

By the end of the mentorship, seven of my patches had been accepted, and several more were still in review.

🛠 **Working on Patches: Finding My Flow**

As I progressed, I shifted focus to areas where I could contribute more consistently:

- Kernel-doc fixes

- Updating comments

- Working on selftests

The selftests work became one of my favorite parts of the mentorship. I wasn’t just fixing documentation anymore, I wrote actual test cases around AF_UNIX: ECONNRESET and EOF behaviors.

Working with reviewers, especially Kuniyuki Iwashima, shaped me a lot. His patience and detailed feedback helped me understand kernel selftest framework and proper testing, which eventually led to the selftest being accepted.

🧰 **Tools I Used and Learned**

Throughout the program, I became comfortable with several important tools:

- Advanced git usage

- syzbot reproducer environments

- QEMU / VM-based testing

- Kernel build system

- Selftest framework

- kernel-doc validator

- Email-based workflows

- Static analysis tools

These improved not only my kernel work but also my day-to-day job as a embedded software / firmware developer.

📚 **Commands and Scripts I Used**

I made up scripts to search for FIXMEs, TODOs, and compile warnings. They helped me discover places where I could contribute. The scripts are available here:
https://github.com/sadelodun/linken-helper-scripts.git

Some example commands I used:

- make CFLAGS=-Wno-error TEST_GEN_PROGS="<name_of_test>"
Build only a specific selftest.

- scripts/kernel-doc -v -Wall -Werror -none <path_to_file>
Check for kernel-doc correctness.

- (Other commands and scripts are included in the repo.)

🧠 **Lessons Learned**

Beyond technical knowledge, the program taught me:

- How to contribute responsibly

- How to write clean, logical patches

- How to communicate clearly with maintainers

- How small changes improve the larger system

- How to analyze bugs

- How to improve based on feedback

- The value of patience in the review cycle

The kernel community is disciplined, structured, and incredibly detailed. Experiencing this firsthand strengthened my overall engineering approach.

🌟 **Personal Growth and Impact**

Even though my contributions were small in the grand scheme of things, the program improved my confidence and my engineering mindset.

As someone working in embedded software / firmware, this mentorship sharpened my debugging skills, deepened my system-level understanding, and improved my professional workflow.

It also inspired me to continue contributing to the kernel beyond the program.

🔚 **Final Thoughts**

The Linux Kernel Bug-Fix Mentorship Program was more than just a mentorship, it was an entry point into world-class open-source engineering.

I’m grateful to everyone involved, especially:

- Shuah Khan

- David Hunter

- And all other persons involved

This experience strengthened my skills, broadened my perspective, and motivated me to keep contributing.

I look forward to doing much more in the future.