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

["Danilo Krummrich" <dakr@kernel.org>]

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.