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: <DCLK1YG1L5TZ.1VMGX131LII9V@kernel.org>
Date: Sat, 06 Sep 2025 09:56:25 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Vitaly Wool" <vitaly.wool@...sulko.se>
Cc: "rust-for-linux" <rust-for-linux@...r.kernel.org>, "LKML"
 <linux-kernel@...r.kernel.org>, "Uladzislau Rezki" <urezki@...il.com>,
 "Danilo Krummrich" <dakr@...nel.org>, "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>, "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 v4 2/2] rust: zpool: add abstraction for zpool drivers

On Thu Aug 28, 2025 at 9:22 AM CEST, Vitaly Wool wrote:
>
>
> On 8/27/25 17:59, Benno Lossin wrote:
>> On Wed Aug 27, 2025 at 4:24 PM CEST, Vitaly Wool wrote:
>>>
>>>
>>>> On Aug 26, 2025, at 7:02 PM, Benno Lossin <lossin@...nel.org> wrote:
>>>>
>>>> On Sat Aug 23, 2025 at 3:05 PM CEST, Vitaly Wool wrote:
>>>>> +pub trait ZpoolDriver {
>>>>> +    /// Opaque Rust representation of `struct zpool`.
>>>>> +    type Pool: ForeignOwnable;
>>>>
>>>> I think this is the same question that Danilo asked a few versions ago,
>>>> but why do we need this? Why can't we just use `Self` instead?
>>>
>>> It’s convenient to use it in the backend implementation, like in the toy example supplied in the documentation part:
>>>
>>> +/// struct MyZpool {
>>> +///     name: &'static CStr,
>>> +///     bytes_used: AtomicU64,
>>> +/// }
>>> …
>>> +/// impl ZpoolDriver for MyZpoolDriver {
>>> +///     type Pool = KBox<MyZpool>;
>>>
>>> Does that make sense?
>> 
>> No, why can't it just be like this:
>> 
>>      struct MyZpool {
>>          name: &'static CStr,
>>          bytes_used: AtomicU64,
>>      }
>>      
>>      struct MyZpoolDriver;
>>      
>>      impl ZpoolDriver for MyZpoolDriver {
>>          type Error = Infallible;
>>      
>>          fn create(name: &'static CStr) -> impl PinInit<Self, Self::Error> {
>>              MyZpool { name, bytes_used: AtomicU64::new(0) }
>>          }
>>      
>>          fn malloc(&mut self, size: usize, gfp: Flags, _nid: NumaNode) -> Result<usize> {
>>              let mut pow: usize = 0;
>>              for n in 6..=PAGE_SHIFT {
>>                  if size <= 1 << n {
>>                      pow = n;
>>                      break;
>>                  }
>>              }
>>              match pow {
>>                  0 => Err(EINVAL),
>>                  _ => {
>>                      let vec = KVec::<u64>::with_capacity(1 << (pow - 3), gfp)?;
>>                      let (ptr, _len, _cap) = vec.into_raw_parts();
>>                      self.bytes_used.fetch_add(1 << pow, Ordering::Relaxed);
>>                      Ok(ptr as usize | (pow - 6))
>>                  }
>>              }
>>          }
>>      
>>          unsafe fn free(&self, handle: usize) {
>>              let n = (handle & 0x3F) + 3;
>>              let uptr = handle & !0x3F;
>>      
>>              // SAFETY:
>>              // - uptr comes from handle which points to the KVec allocation from `alloc`.
>>              // - size == capacity and is coming from the first 6 bits of handle.
>>              let vec = unsafe { KVec::<u64>::from_raw_parts(uptr as *mut u64, 1 << n, 1 << n) };
>>              drop(vec);
>>              self.bytes_used.fetch_sub(1 << (n + 3), Ordering::Relaxed);
>>          }
>>      
>>          unsafe fn read_begin(&self, handle: usize) -> NonNull<u8> {
>>              let uptr = handle & !0x3F;
>>              // SAFETY: uptr points to a memory area allocated by KVec
>>              unsafe { NonNull::new_unchecked(uptr as *mut u8) }
>>          }
>>      
>>          unsafe fn read_end(&self, _handle: usize, _handle_mem: NonNull<u8>) {}
>>      
>>          unsafe fn write(&self, handle: usize, handle_mem: NonNull<u8>, mem_len: usize) {
>>              let uptr = handle & !0x3F;
>>              // SAFETY: handle_mem is a valid non-null pointer provided by zpool, uptr points to
>>              // a KVec allocated in `malloc` and is therefore also valid.
>>              unsafe {
>>                  copy_nonoverlapping(handle_mem.as_ptr().cast(), uptr as *mut c_void, mem_len)
>>              };
>>          }
>>      
>>          fn total_pages(&self) -> u64 {
>>              self.bytes_used.load(Ordering::Relaxed) >> PAGE_SHIFT
>>          }
>>      }
>
> It can indeed but then the ZpoolDriver trait will have to be extended 
> with functions like into_raw() and from_raw(), because zpool expects 
> *mut c_void, so on the Adapter side it will look like
>
>      extern "C" fn create_(name: *const c_uchar, gfp: u32) -> *mut c_void {
>          // SAFETY: the memory pointed to by name is guaranteed by zpool 
> to be a valid string
>          let pool = unsafe { T::create(CStr::from_char_ptr(name), 
> Flags::from_raw(gfp)) };
>          match pool {
>              Err(_) => null_mut(),
>              Ok(p) => T::into_raw(p).cast(),
>          }
>      }
>
> The question is, why does this make it better?

No, thanks for sharing that function. Then the question becomes, do you
really need `ForeignOwnable`? Or is `KBox` enough? Do you really want
people to use `Arc<MyZPool>`? Because `BorrowedMut` of `Arc` is the same
as it's `Borrowed` variant (it's read-only after all).

If you can get away with just `Box` (you might want people to choose
their allocator, which is fine IMO), then I'd do so.

---
Cheers,
Benno

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ