linux-kernel - Re: [PATCH v2 1/2] rust: introduce abstractions for fwctlg

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: <20260128192614.6bce6eab.zhiw@nvidia.com>
Date: Wed, 28 Jan 2026 19:26:14 +0200
From: Zhi Wang <zhiw@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Danilo Krummrich <dakr@...nel.org>, <rust-for-linux@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<aliceryhl@...gle.com>, <bhelgaas@...gle.com>, <kwilczynski@...nel.org>,
	<ojeda@...nel.org>, <alex.gaynor@...il.com>, <boqun.feng@...il.com>,
	<gary@...yguo.net>, <bjorn3_gh@...tonmail.com>, <lossin@...nel.org>,
	<a.hindborg@...nel.org>, <tmgross@...ch.edu>, <markus.probst@...teo.de>,
	<helgaas@...nel.org>, <cjia@...dia.com>, <smitra@...dia.com>,
	<ankita@...dia.com>, <aniketa@...dia.com>, <kwankhede@...dia.com>,
	<targupta@...dia.com>, <acourbot@...dia.com>, <joelagnelf@...dia.com>,
	<jhubbard@...dia.com>, <zhiwang@...nel.org>, <daniel.almeida@...labora.com>
Subject: Re: [PATCH v2 1/2] rust: introduce abstractions for fwctlg

On Wed, 28 Jan 2026 12:39:27 -0400
Jason Gunthorpe <jgg@...dia.com> wrote:

> On Wed, Jan 28, 2026 at 05:35:04PM +0100, Danilo Krummrich wrote:
> > On Wed Jan 28, 2026 at 4:56 PM CET, Jason Gunthorpe wrote:
> > > On Wed, Jan 28, 2026 at 04:49:07PM +0100, Danilo Krummrich wrote:
> > >
> > >> 	        // Initialize the `data` initializer within the
> > >> memory pointed // to by `raw_data`.
> > >> 	        unsafe { data.__pinned_init(raw_data)
> > >> }.inspect_err(|_| {
> > >
> > >> So, essentially the driver passes an initializer of its private
> > >> data and we "write" this initializer into the extra memory
> > >> allocated with _fwctl_alloc_device().
> > >
> > > This all seems like the right way to do it!
> > >
> > > My only remark it that it still doesn't give an opportunity to call a
> > > function between init and register.
> > 
> > You would, from a driver side it would look like this:
> > 
> > 	#[pin_data]
> > 	struct MyDriver {
> > 	    #[pin]
> > 	    _reg: Devres<fwctl::Registration>,
> > 	    fwctl: ARef<fwctl::Device>,
> > 	}
> > 
> > 	#[pin_data]
> > 	struct FwctlData {
> > 	    #[pin]
> > 	    foo: Mutex<Foo>,
> > 	    ...,
> > 	}
> > 
> > 	impl pci::Driver for MyDriver {
> > 	    fn probe(
> > 	        pdev: &pci::Device<Core>,
> > 	        _info: &Self::IdInfo,
> > 	    ) -> impl PinInit<Self, Error> {
> > 	        let fwctl = fwctl::Device::new(
> > 	            pdev.as_ref(),
> > 	            try_pin_init!(FwctlData {
> > 	                foo <- mutex_new!(Foo::new()),
> > 	                ...,
> > 	            }),
> > 	        )?;
> > 
> > 	        // Let's do something with the `fwctl::Device` before
> > we // register it.
> > 	        fwctl.do_stuff();
> > 
> > 	        try_pin_init!(Self {
> > 	            // We could omit this and instead provide
> > 	            // `fwctl::Registration::register()`, which does
> > only return // a `Result` and keeps the `fwct::Device` registered until
> > 	            // driver unbind.
> > 	            _reg <- fwctl::Registration::new(pdev.as_ref(),
> > fwctl); fwctl,
> > 	        })
> > 	    }
> > 	}
> 
> Okay it is fine by me, Zi did you get all this?
> 

Yes. These will be addressed in the next re-spin.

> Jason