Repository navigation
Description
Just like checkpatch.pl tells developers that they should do their best to avoid BUG* calls (and if they do, they should be ready to justify them), unwrap()s (and similar panicking APis like expect()) in the Rust side are also equally damaging (at least at the moment) since a Rust panic currently calls BUGs too.
There are cases where unwrap() is justified (just like unsafe/unchecked operations), but in many cases developers may reach for unwrap() when there are better alternatives (e.g. reorganizing the code to avoid that case to start with). Even if there is no better alternative and it may be locally obvious that it is an impossible condition, using unwrap() and similar APIs should be a conscious decision.
Thus introduce a checkpatch.pl warning for common panicking methods such as unwrap() and expect() to make developers think twice about it, as well as to make it easier for maintainers to catch any such use when they check patches they receive.
Notes:
-
We are more lenient with
unwrap()s withinassert*!s calls within doctests, but it may still be fine to warn on those incheckpatch.pl. -
We want to introduce further linting at the source code level for some of those in the future, requiring
// PANIC: ...comments (// PANICcomment on panic-able calls rust-lang/rust-clippy#15861, Lint to require// PANIC: ...comments rust-lang/rust-clippy#15895, Lint to detect unneeded// PANIC: ...comments rust-lang/rust-clippy#15896).
This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag, and a Link: tag to this issue. Please see https://docs.kernel.org/process/submitting-patches.html and https://rust-for-linux.com/contributing for details.
Activity
tot0rokr commentedon Jan 13, 2026
Hi @ojeda .
Are you still waiting on a fix for this issue? If so, I’d be happy to take it on and work on a patch.
Would it be a good approach to address this by updating checkpatch.pl to parse unwrap() calls with a regex and emit a warning? Is there anything else I should look at or reference before I start?
ojeda commentedon Jan 13, 2026
That would be nice from our side, but please note that there may not be much bandwidth on the
checkpatch.plside -- we have a few old, pending patches in the list forcheckpatch.pl(helping to move those forward, for instance reviewing them, would be nice as well).Thus, if you decide to work on it, then please keep it as simple as reasonably possible, so that it is as easy to review as possible and thus to land.
Thanks!
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: warn on Rust panicking methods
onur-ozkan commentedon Feb 3, 2026
Is there a specific reason we are not using clippy for this? It already has unwrap_used and expect_used rules.
scripts: checkpatch: move Rust-specific lints to separate file
ojeda commentedon Feb 5, 2026
For reference, I gave some context at https://lore.kernel.org/rust-for-linux/CANiq72=J5LBxfawu3MtQpcukaXcw+pRyMWd9ueDE=od4X99R3w@mail.gmail.com/.
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: move Rust-specific lints to separate file
scripts: checkpatch: add RUST_UNWRAP lint
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: warn on Rust panicking methods
scripts: checkpatch: add RUST_UNWRAP lint
scripts: checkpatch: warn on Rust panicking methods