Introduction
Motivated by the series of events I describe below, I decided to write this short blog post about how fixing Coverity issues can open the door to your first meaningful contributions to the Linux kernel. I hope people find it both inspiring and useful. 🙂
Kernel Newbies and Kernel Janitors
In October last year, I replied the following to an email sent to the kernel-janitors mailing list.
> Yesterday someone on my lists just sent an email looking for kernel
> tasks. This was a university student in a kernel programming class.
> We also have kernel-janitors and outreachy and those people are always
> asking for small tasks.
We have tons of issues waiting to be audited and fixed here:
https://scan.coverity.com/projects/linux-next-weekly-scan
You will never run out of fun. :) People just need to sign up.
That's really a great way to learn and gain experience across the whole
kernel tree.
--
Gustavo
At the time, my response didn’t gain much traction. However, early this month, I came across a familiar message on the kernel newbies mailing list asking for guidance on how to contribute to the Linux kernel.
Hi all,
I am an embedded software engineer. I use Linux every day, and I appreciate its neatness and simplicity.
One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I started wondering if maybe I could contribute to the Linux kernel. So, I sent a very simple (and maybe stupid) patch to the community:
[...]
It turns out that the patch was rejected.
So, my question is: how can I start contributing to the Linux kernel? Maybe I could start by fixing some small bugs?
Thanks,
Qianqiang Liu
To which I replied:
Hi!
> One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I started wondering if maybe I could contribute to the Linux kernel.
If you are interested in security, fixing Coverity issues is a great way to
contribute to the kernel. Here are some presentations that you might find
useful:
https://embeddedor.com/slides/2017/kr/kr2017.pdf
https://embeddedor.com/slides/2018/kr/kr2018.pdf
https://embeddedor.com/slides/2019/kr/kr2019.pdf
You can also watch these presentations on YouTube for additional context.
You can sign up here for linux-next scans:
https://scan.coverity.com/projects/linux-next-weekly-scan
and here for -rc scans:
https://scan.coverity.com/projects/linux
I hope this helps.
--
Gustavo
Later that day, I received a couple of notifications informing me that someone was requesting access to the Linux kernel Coverity scans. I granted the access and forget about it.
Fixing Coverity issues
Then, early last week, an email from that same thread landed my inbox:
Hi,
Thank you all for the good advice.
I have now successfully submitted some small changes to the kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b4af913465cc5f903227237d833b4911430fd97
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=590efcd3c75f0e1f7208cf1c8dff5452818b70f2
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fd551a87ba427fee2df8af4d83f4b7c220cc9dd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93497752dfed196b41d2804503e80b9a04318adb
Contributing to the Linux kernel is not that hard, all we need is
patience and persistence.
I definitely will do more work on the Linux kernel!
--
Best,
Qianqiang Liu
I was so happy to discover that those patches looked quite similar to the ones I used to submit back in the day when I was trying to land my first Coverity fixes. Then in a subsequent email, this was confirmed:
Hi Malatesh,
> Can you help me to contribute, what I needs to do ?
You can refer to this mail thread. The advice from Gustavo is pretty
useful.
Also, there is a document for submitting your first kernel patch:
https://kernelnewbies.org/FirstKernelPatch
--
Best,
Qianqiang Liu
Send patches, gain experience
Even though, at the time I started working in the Linux kernel I already had solid experience in embedded systems, C programming, and had taken a Linux kernel development training, I was totally new to the Linux kernel community and all the nuances around upstream contributions in particular. As I was about to learn over the years, this is what is actually crucial for becoming a successful kernel contributor. However, gaining this experience takes time, and the only way to become an experienced contributor, as you might have guessed, is to send tons of patches.
Bug fixing presentations
So, for those interested in landing their first kernel patches, one simple way to start gaining experience contributing to the Linux kernel is by fixing as many Coverity issues as possible. I promise you’ll learn a lot in the process. 😉
Check out the following presentations, where I dive deep into fixing Coverity issues and other problems in the Linux kernel:
- Fixing coverity bugs all around the Linux kernel (Kernel Recipes 2017)
- A year of fixing Coverity issues all over the Linux kernel (Kernel Recipes 2018)
- Hunting and fixing bugs all over the Linux kernel (Kernel Recipes 2019)
And of course, sign up for linux-next (despite being named “linux-next weekly scan”, these are actually daily scans) and -rc Coverity scans. It’d be helpful if you could briefly mention this blog post in your request message when signing up, though it’s not required. Also, I encourage you to make sure you know how to submit a kernel patch. 🙂
Learn from existing contributions
Back in the day, when I started fixing issues in the kernel, it was not uncommon for me to feel a bit lost from time to time. One of the best things you can do in those situations is to look at what others are currently working on in your areas of interest.
In this case, one simple approach is to check the commits addressing Coverity issues that have recently landed in linux-next. The link below will take you to a list of all kernel patches in linux-next that contain the keyword Coverity in their changelog text.
I recommend studying them. If you don’t understand how people concluded that that was the right fix for the issue, take it a step further and look up the email thread that initiated the discussion and read it thoroughly to understand what is going on. This can be a great learning experience. 😉
Below is a link to all the Linux kernel mailing lists, including of course The Linux Kernel Mailing List or LKML:
You can start by checking LKML. However, it’s not uncommon for developers to omit that list and send their patches only to the relevant subsystem mailing lists. So, if you don’t find the thread on LKML, look it up on the other lists. Depending on the driver the patch affects, it should be obvious which lists to check.
Lastly, when you send a patch addressing Coverity issues, please briefly mention that in the changelog text. A simple Reported by Coverity is enough. This way, others can easily find your commits in the future and learn from your contributions as well. 🙂
Try in staging first
As a final piece of advice, I recommend starting by fixing issues in drivers/staging/. After landing several patches and gaining some experience from the feedback provided by the staging maintainers, you will feel more comfortable moving on to other areas of the kernel.
Each subsystem and driver in the kernel is usually maintained by different groups of people, each with their own way of doing things and their own idiosyncrasies. Adapting to these different methods is one the most important pieces of experience you will gain as you continue submitting patches and paying attention to the feedback you receive along the way. Always remember: upstream Linux kernel development is highly social. 😉
Enjoy!
