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: <E2F129BE-777A-4DBD-BC3E-44033BCD11E4@collabora.com>
Date: Fri, 16 May 2025 13:57:59 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
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

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. In order words, it converts *from* &self to another type:

pub trait AsRef<T>
where
T: ?Sized,
{
    // Required method
    fn as_ref(&self) -> &T;
}

The signature in the kernel is different, i.e.:

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

This takes a pointer and converts *to* &self, which is a bit in the wrong
direction IMHO. You also have to provide `ptr`, which is a departure from the
syntax used elsewhere in Rust, i.e.:

// no explicit arguments:
let bar: &Bar = foo.as_ref();

vs

// slightly confusing:
//
// Bar::as_ref() creates &Bar instead of taking it as an argument to return something else
let bar = Bar::as_ref(foo_ptr);   


Which is more akin to how the "from" prefix works, starting from the From trait
itself, i.e.:

let bar  = Bar::from(...); // Ok: creates Bar,

...to other similar nomenclatures:

let bar = Bar::from_ptr(foo_ptr); // Ok, creates &Bar

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.

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