linux-kernel - Re: [PATCH v10 4/6] rust: enable `clippy::as

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: <CAJ-ks9ny_VNvKM-w04kkk4Yw=UpYEt82TyFZZuXEFK=DxfwcgQ@mail.gmail.com>
Date: Tue, 10 Jun 2025 10:13:50 -0400
From: Tamir Duberstein <tamird@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...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@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Brendan Higgins <brendan.higgins@...ux.dev>, 
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Luis Chamberlain <mcgrof@...nel.org>, 
	Russ Weight <russ.weight@...ux.dev>, Rob Herring <robh@...nel.org>, 
	Saravana Kannan <saravanak@...gle.com>, Abdiel Janulgue <abdiel.janulgue@...il.com>, 
	Daniel Almeida <daniel.almeida@...labora.com>, Robin Murphy <robin.murphy@....com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	FUJITA Tomonori <fujita.tomonori@...il.com>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Frederic Weisbecker <frederic@...nel.org>, Lyude Paul <lyude@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Anna-Maria Behnsen <anna-maria@...utronix.de>, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	kunit-dev@...glegroups.com, linux-pci@...r.kernel.org, 
	linux-block@...r.kernel.org, devicetree@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, netdev@...r.kernel.org
Subject: Re: [PATCH v10 4/6] rust: enable `clippy::as_underscore` lint

On Sun, Jun 8, 2025 at 5:06 PM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Fri, Apr 18, 2025 at 5:37 PM Tamir Duberstein <tamird@...il.com> wrote:
> >
> > -            bindings::BLK_STS_OK as _
> > +            bindings::BLK_STS_OK as u8
>
> > -        unsafe { bindings::blk_mq_end_request(request_ptr, bindings::BLK_STS_OK as _) };
> > +        unsafe { bindings::blk_mq_end_request(request_ptr, bindings::BLK_STS_OK as u8) };
>
> For these two: `BLK_STS_OK` was discussed in a previous version, but
> why are we not using `blk_status_t` type instead?
>
> We are even already using it in the first case, and in the second it
> is the parameter's type.
>
> > -/// # use kernel::{bindings, c_str, device::Device, devres::Devres, io::{Io, IoRaw}};
> > +/// # use kernel::{bindings, c_str, device::Device, devres::Devres, ffi::c_void, io::{Io, IoRaw}};
>
> For v11 this can be removed since it is now in the prelude. There may
> others that can be removed too (I would not add an import just to use
> it in these patches, but if the prelude is already imported, then we
> should use it).
>
> > -        result.minor = bindings::MISC_DYNAMIC_MINOR as _;
> > +        result.minor = bindings::MISC_DYNAMIC_MINOR as i32;
>
> Similarly here, shouldn't we use `c_int`?
>
> i.e. it is the one in the C side, not the "resolved" `i32` that the
> compiler suggests.
>
> > -                    bindings::wq_misc_consts_WORK_CPU_UNBOUND as _,
> > +                    bindings::wq_misc_consts_WORK_CPU_UNBOUND as i32,
>
> Similarly, this should probably be `c_int` since that is the
> parameter's type, right?

Yeah, I think these are good calls - I'll fix it in v11. When would
you like me to send it?