lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260203193240.68bb136e@nimda>
Date: Tue, 3 Feb 2026 19:32:40 +0300
From: Onur Özkan <work@...rozkan.dev>
To: "Gary Guo" <gary@...yguo.net>
Cc: "Jkhall81" <jason.kei.hall@...il.com>, <dirk.behme@...bosch.com>,
 <joe@...ches.com>, <ojeda@...nel.org>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

On Tue, 03 Feb 2026 16:02:02 +0000
"Gary Guo" <gary@...yguo.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@...il.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.
> >> 
> >> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ