linux-kernel - Re: [RFC PATCH 1/2] rust: add initial scatterlist bindings

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: <aCd8D5IA0RXZvtcv@pollux>
Date: Fri, 16 May 2025 19:55:27 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Abdiel Janulgue <abdiel.janulgue@...il.com>, lyude@...hat.com,
	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>,
	Valentin Obst <kernel@...entinobst.de>,
	open list <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Robin Murphy <robin.murphy@....com>, airlied@...hat.com,
	rust-for-linux@...r.kernel.org,
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>,
	Petr Tesarik <petr@...arici.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Sui Jingfeng <sui.jingfeng@...ux.dev>,
	Randy Dunlap <rdunlap@...radead.org>,
	Michael Kelley <mhklinux@...look.com>
Subject: Re: [RFC PATCH 1/2] rust: add initial scatterlist bindings

On Fri, May 16, 2025 at 01:57:59PM -0300, Daniel Almeida wrote:
> Hi Danilo, 
> 
> Replying to you and Lyude here at the same time.
> 
> > On 15 May 2025, at 18:11, Danilo Krummrich <dakr@...nel.org> wrote:
> > 
> > On Mon, May 12, 2025 at 08:39:36AM -0300, Daniel Almeida wrote:
> >>> On 12 May 2025, at 06:53, Abdiel Janulgue <abdiel.janulgue@...il.com> wrote:
> >>> +impl SGEntry {
> >>> +    /// Convert a raw `struct scatterlist *` to a `&'a SGEntry`.
> >>> +    ///
> >>> +    /// # Safety
> >>> +    ///
> >>> +    /// Callers must ensure that the `struct scatterlist` pointed to by `ptr` is valid for the lifetime
> >>> +    /// of the returned reference.
> >>> +    pub unsafe fn as_ref<'a>(ptr: *mut bindings::scatterlist) -> &'a Self {
> >>> +        // SAFETY: The pointer is valid and guaranteed by the safety requirements of the function.
> >>> +        unsafe { &*ptr.cast() }
> >>> +    }
> >> 
> >> Hmm, this name is not good. When people see as_ref() they will think of the
> >> standard library where it is used to convert from &T to &U. This is not what is
> >> happening here. Same in other places where as_ref() is used in this patch.
> > 
> > as_ref() is fine, we use this exact way commonly in the kernel, e.g. for Device,
> > GlobalLockedBy, Cpumask and for various DRM types.
> > 
> > Rust std does the same, e.g. in [1].
> > 
> > I think I also asked for this in your Resource patch for consistency, where you
> > call this from_ptr() instead.
> > 
> > [1] https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_ref
> > 
> 
> That is not the same thing. What you've linked to still takes &self and returns
> &T.

Fair enough. :)

> So, IMHO, the problem is not conflicting with the std AsRef, in the sense that the
> code might not compile because of it. The problem is taking a very well
> known name and then changing its semantics.

I don't see the problem, a function signature is always read as a whole, in this
case:

	fn as_ref<'a>(ptr: *mut bindings::foo) -> &'a Self

which reads as "take this pointer and give me a reference", i.e. "as ref".

Anyways, I'm not very much opinionated about the exact name, I care about
consistency.

So, if you feel like we should name it differently, please also change the
existing functions in the kernel.

> Anyways, this is just a small observation. I'll drop my case, specially
> considering that the current as_ref() is already prevalent in a lot of code upstream :)
> 
> — Daniel
>