Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

["Onur Özkan" <work@onurozkan.dev>]

On Tue, 03 Feb 2026 16:02:02 +0000
"Gary Guo" <gary@garyguo.net> wrote:

> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
> > On Tue,  3 Feb 2026 08:25:41 -0700
> > Jkhall81 <jason.kei.hall@gmail.com> wrote:
> >
> >> Nice, emails sent from gmail get automatically rejected.
> >> 
> >> So, Dirk.  To satisfy your concerns the current 10ish line
> >> code update is going to slowly, after many more emails
> >> written in nano, mutate into a franken-regex-perl beast. 
> >> checkpatch.pl is already huge.  I'm not a fan of this 
> >> approach.
> >
> > Me neither. I wonder why we are doing this instead of using the
> > unwrap_used and expect_used linting rules from clippy. This would
> > catch the problem much earlier than checkpath since many of us build
> > the kernel with CLIPPY=1 flag.
> 
> Because it's okay to `panic` or use `expect`. checkpatch will just
> warn you once when the code is introduced, not continuously in each
> build.

That's interesting because it implies that it's okay for people to use
them without "// PANIC..." comments. That sounds problematic since it
means some instances will have that comment while others may not.

In my opinion, adding a clippy rule and using "#[allow(...)]" in the
places where it's acceptable to use them makes more sense. This is at
least more consistent and doesn't bloat the checkpatch file.

Thanks,
Onur

> 
> Best,
> Gary
> 
> >
> > Regards,
> > Onur
> >
> >> 
> >> We could just not do this. Right now we are trying to
> >> get a warning if someone uses rust code that can cause a
> >> panic.  Software Engineers are smart people.  What if they
> >> just don't use rust code that causes panics inside core
> >> files.  Problem solved.
> >> 
> >> 
>