linux-kernel - Re: [PATCH v2] rust: zpool: add abstraction for zpool drivers

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] [day] [month] [year] [list]

Message-Id: <DC86GM7VK8PH.QYLPP2SLYM3M@kernel.org>
Date: Thu, 21 Aug 2025 16:32:39 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Vitaly Wool" <vitaly.wool@...sulko.se>
Cc: <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 "Uladzislau Rezki" <urezki@...il.com>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Vlastimil Babka" <vbabka@...e.cz>, "Lorenzo Stoakes"
 <lorenzo.stoakes@...cle.com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>,
 "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>,
 "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>, "Bjorn
 Roy Baron" <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>,
 "Andreas Hindborg" <a.hindborg@...nel.org>, "Trevor Gross"
 <tmgross@...ch.edu>, "Johannes Weiner" <hannes@...xchg.org>, "Yosry Ahmed"
 <yosry.ahmed@...ux.dev>, "Nhat Pham" <nphamcs@...il.com>,
 <linux-mm@...ck.org>
Subject: Re: [PATCH v2] rust: zpool: add abstraction for zpool drivers

On Thu Aug 21, 2025 at 4:15 PM CEST, Vitaly Wool wrote:
>
>
> On 8/21/25 14:32, Danilo Krummrich wrote:
>> On Thu Aug 21, 2025 at 2:03 PM CEST, Danilo Krummrich wrote:
>>> On Thu Aug 21, 2025 at 1:17 PM CEST, Vitaly Wool wrote:
>>>> +    /// preferred NUMA node `nid`. If the allocation is successful, an opaque handle is returned.
>>>> +    fn malloc(
>>>> +        pool: <Self::Pool as ForeignOwnable>::BorrowedMut<'_>,
>>>> +        size: usize,
>>>> +        gfp: Flags,
>>>> +        nid: NumaNode,
>>>> +    ) -> Result<usize>;
>>>
>>> I still think we need a proper type representation of a zpool handle that
>>> guarantees validity and manages its lifetime.
>>>
>>> For instance, what prevents a caller from calling write() with a random handle?
>>>
>>> Looking at zsmalloc(), if I call write() with a random number, I will most
>>> likely oops the kernel. This is not acceptable for safe APIs.
>>>
>>> Alternatively, all those trait functions have to be unsafe, which would be very
>>> unfortunate.
>> 
>> I just noticed that I confused something here. :)
>> 
>> So, for the backend driver this trait is obviously fine, since you have to implement
>> the C ops -- sorry for the confusion.
>> 
>> However, you still have to mark all functions except alloc() and total_pages()
>> as unsafe and document and justify the corresponding safety requirements.
>
> How is destroy() different from alloc() in terms of safety? I believe 
> it's only free, read_{begin|end}, write that should be marked as unsafe.

destroy() should be fine.