Week 12 — Your First Contribution¶

Goal¶

Find real, submittable work in the networking tree. Understand the different types of contributions and which are appropriate for your skill level. Send your first patch.

Why This Matters¶

The hardest part of becoming a kernel contributor is not the code — it's knowing where to start. This week gives you concrete strategies for finding work, from trivial cleanups to meaningful bug fixes.

Contribution Types (Ordered by Difficulty)¶

1. Fix checkpatch Warnings (Easiest, but use sparingly)¶

# Find files with checkpatch issues
./scripts/checkpatch.pl --file net/ipv4/tcp.c
./scripts/checkpatch.pl --file net/core/dev.c

These are style fixes: whitespace, line length, missing blank lines. They're the traditional "first patch" but maintainers have mixed feelings about them — too many trivial style patches waste review bandwidth.

Do: Fix a checkpatch warning if you're already touching the code for another reason. Don't: Send a patch that only fixes whitespace in a file you don't understand.

2. Fix Coccinelle/Sparse/Smatch Warnings (Better)¶

These tools find real code issues:

# Run sparse on networking code
make C=2 M=net/ipv4/

# Run coccinelle
make coccicheck MODE=report M=net/

# Run smatch
make CHECK="smatch -p=kernel" C=2 M=net/core/

Examples of fixable findings: - Unnecessary NULL checks before kfree() (kfree handles NULL) - Missing error code propagation - Unused variables - Incorrect type annotations (__user, __rcu, __be32, etc.)

3. Fix Compiler Warnings with W=1¶

make W=1 net/ipv4/tcp.o 2>&1 | head -30
make W=1 M=net/ 2>&1 | grep warning

These can reveal real issues: unused functions, implicit type conversions, missing prototypes.

4. Improve Documentation¶

Networking code often has outdated or missing comments:

# Find TODO/FIXME/HACK in networking code
grep -rn 'TODO\|FIXME\|HACK\|XXX' net/ | head -30

# Look at kernel-doc coverage
./scripts/kernel-doc -none net/ipv4/tcp.c 2>&1 | grep -i warning

Good documentation contributions: - Add kernel-doc comments to exported functions that lack them - Fix incorrect function documentation - Update comments that reference old behavior

5. Fix syzkaller Bugs (Intermediate)¶

Browse open bugs: https://syzkaller.appspot.com/upstream

Filter for networking bugs. Look for bugs with: - A C reproducer (easier to work with) - Recent reports (still present in mainline) - Clear stack traces in networking code

Workflow:

# 1. Read the bug report
# 2. Build a kernel with KASAN enabled
# 3. Run the reproducer in QEMU
# 4. Reproduce the crash
# 5. Read the stack trace
# 6. Find the root cause in the code
# 7. Write a fix
# 8. Verify the reproducer no longer crashes
# 9. Send the patch with Fixes: tag

6. Clean Up Deprecated API Usage (Intermediate)¶

The kernel regularly deprecates old APIs. Commits like "net: convert X to use Y" are common and welcome. Watch for:

# Find deprecated function usage
grep -rn 'prandom_u32\|strlcpy\|strncpy' net/ | head -20

# Check for old-style timer setup
grep -rn 'setup_timer\|init_timer' net/ | head -20

# Find raw access to sk_buff data (should use helpers)
grep -rn 'skb->data\[' net/ | head -20

7. Add Missing Error Handling (Intermediate)¶

Look for functions that ignore return values:

# Functions that return error codes but callers ignore them
grep -rn 'nla_put(' net/ | grep -v 'if.*nla_put\|goto\|return' | head -20

8. Improve Selftest Coverage (Intermediate-Advanced)¶

# See what tests exist
ls tools/testing/selftests/net/

# Look at recent test additions for patterns
git log --oneline tools/testing/selftests/net/ | head -20

Contributing a test for an untested code path is valuable and teaches you the subsystem deeply.

9. Implement Missing Features (Advanced)¶

Watch the mailing list for discussions about wanted features. Also check:

# Feature requests and discussions on netdev
# Subscribe and read daily — you'll notice gaps and requests

# Look at TODO files
find net/ -name 'TODO' -o -name 'todo'

10. Fix Real Bugs from Bug Reports (Advanced)¶

Monitor: - netdev mailing list for bug reports - Bugzilla: https://bugzilla.kernel.org/ (Networking component) - Syzkaller dashboard

How to Find Your First Patch¶

Here's a concrete strategy for the next few days:

Strategy A: The Coccinelle Path¶

cd ~/linux

# Run coccinelle on networking core
make coccicheck MODE=report M=net/core/ 2>&1 | tee /tmp/cocci-report.txt

# Look for actionable findings
cat /tmp/cocci-report.txt | grep -B2 "should use\|could be\|unnecessary"

Pick one finding. Understand the code around it. Make the fix. Test it. Send it.

Strategy B: The Deprecation Path¶

Look at recent tree-wide cleanup commits for patterns:

git log --oneline --all --author='' -- net/ | grep -i 'deprecat\|convert\|replace\|remove.*unused'

Find similar patterns that weren't caught in the tree-wide sweep.

Strategy C: The Selftest Path¶

Pick a networking feature you understand (e.g., TCP keepalive). Check if it has tests:

grep -rl 'keepalive' tools/testing/selftests/net/

If not, write a test. This is a great contribution — it's useful, teaches you the feature deeply, and is less likely to be rejected than a code change.

Strategy D: The Bug Report Path¶

Go to https://syzkaller.appspot.com/upstream and find a recent networking crash report with a reproducer. Even if you can't fix it, you might be able to: - Bisect it to find the guilty commit - Write a minimal reproducer - Identify the root cause

Before You Send: Final Checklist¶

# 1. Your change compiles cleanly
make -j$(nproc)

# 2. No new warnings
make W=1 net/ipv4/your_file.o

# 3. Sparse is happy
make C=1 net/ipv4/your_file.o

# 4. checkpatch passes
./scripts/checkpatch.pl 0001-your-patch.patch

# 5. Your commit message is correct
#    - Proper subject prefix (net: or net-next:)
#    - Explains the problem and the fix
#    - Has Signed-off-by
#    - Has Fixes: if applicable

# 6. get_maintainer.pl output noted
./scripts/get_maintainer.pl 0001-your-patch.patch

# 7. Boots and basic networking works in QEMU

# 8. Relevant selftests pass

# 9. Send to yourself first and verify formatting
git send-email --to=your@email.com 0001-your-patch.patch

After Sending: What to Expect¶

Within hours: Automated CI bots may reply with test results
Within days: Patchwork shows your patch status
Within 1-2 weeks: Reviewers may comment
Possible outcomes:
Accepted (applied to net or net-next)
Changes requested (send v2)
Rejected with explanation
Silence (ping after 2 weeks)

If changes are requested: Don't take it personally. Kernel review is direct and blunt. Fix the issues, thank the reviewer, send v2.

Building a Reputation¶

Long-term contributor strategy:

Start small — cleanups, test improvements, documentation
Be consistent — one patch per month is better than ten patches once
Review others' patches — you don't need to be a maintainer to review
Attend conferences — Netdev Conf, Linux Plumbers, Kernel Summit
Pick a sub-area — become the person who knows IPv6 multicast or TCP congestion control or netfilter deeply
Respond to requests — when someone on the list asks "can someone test X on Y", volunteer
Read LWN.net — stay current with kernel development trends

Exercises¶

Run coccinelle on net/core/ and net/ipv4/. Find one actionable result. Understand the code. Write a fix.
Run checkpatch.pl on a file you've been studying. If there are issues, fix one and create a proper patch.
Browse the netdev mailing list archive (https://lore.kernel.org/netdev/) for the past week. Read three patch discussions. Note the review style.
Go to the syzkaller dashboard and find a networking bug with a reproducer. Try to reproduce it in your QEMU setup.
Write a kselftest for a simple networking operation (e.g., setting socket options, basic TCP echo). Follow the format of existing tests.
Send your first patch. Even if it's a trivial fix, the process is what matters.

What's Next¶

You're no longer following a guide — you're following the mailing list. Keep building, keep reading code, keep submitting patches. The path from here is: contributor → regular contributor → reviewer → subsystem expertise → whatever you want.