linux-kernel - Re: [PATCH 04/19] rust: enable `clippy::undocumented_unsafe

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: <CALNs47udN4_Gr2KHDapwWAmY=ixoJN+-9apAShVT7qFcKdK23Q@mail.gmail.com>
Date: Sun, 29 Sep 2024 00:33:25 -0400
From: Trevor Gross <tmgross@...ch.edu>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH 04/19] rust: enable `clippy::undocumented_unsafe_blocks` lint

On Wed, Sep 4, 2024 at 4:45 PM Miguel Ojeda <ojeda@...nel.org> wrote:
>
> Checking that we are not missing any `// SAFETY` comments in our `unsafe`
> blocks is something we have wanted to do for a long time, as well as
> cleaning up the remaining cases that were not documented [1].
>
> Back when Rust for Linux started, this was something that could have
> been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0,
> Clippy implemented the `undocumented_unsafe_blocks` lint [2].
>
> Even though the lint has a few false positives, e.g. in some cases where
> attributes appear between the comment and the `unsafe` block [3], there
> are workarounds and the lint seems quite usable already.
>
> Thus enable the lint now.
>
> We still have a few cases to clean up, so just allow those for the moment
> by writing a `TODO` comment -- some of those may be good candidates for
> new contributors.
>
> Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]
> Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2]
> Link: https://github.com/rust-lang/rust-clippy/issues/13189 [3]
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>

> @@ -277,6 +279,8 @@ pub(crate) fn from_err_ptr<T>(ptr: *mut T) -> Result<*mut T> {
>      if unsafe { bindings::IS_ERR(const_ptr) } {
>          // SAFETY: The FFI function does not deref the pointer.
>          let err = unsafe { bindings::PTR_ERR(const_ptr) };
> +
> +        #[allow(clippy::unnecessary_cast)]
>          // CAST: If `IS_ERR()` returns `true`,
>          // then `PTR_ERR()` is guaranteed to return a
>          // negative value greater-or-equal to `-bindings::MAX_ERRNO`,
> @@ -286,7 +290,6 @@ pub(crate) fn from_err_ptr<T>(ptr: *mut T) -> Result<*mut T> {
>          //
>          // SAFETY: `IS_ERR()` ensures `err` is a
>          // negative value greater-or-equal to `-bindings::MAX_ERRNO`.
> -        #[allow(clippy::unnecessary_cast)]
>          return Err(unsafe { Error::from_errno_unchecked(err as core::ffi::c_int) });
>      }

There are a couple places where the attributes move like this - did
this come from an older clippy version? clippy used to warn about this
but accepts it by default since [1]. (Still works of course, I just
think it looks nicer to have the attributes next to their statements).

Either way:

Reviewed-by: Trevor Gross <tmgross@...ch.edu>

[1]: https://github.com/rust-lang/rust-clippy/pull/11170