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

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: <DFZN5P8G6MQG.2DYXNFSRIL450@kernel.org>
Date: Tue, 27 Jan 2026 21:07:37 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Zhi Wang" <zhiw@...dia.com>
Cc: "Jason Gunthorpe" <jgg@...dia.com>, <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 fwctl

On Tue Jan 27, 2026 at 8:57 PM CET, Zhi Wang wrote:
> The fwctl_alloc_device() helper allocates a raw struct fwctl_device
> without private driver data here. The Rust driver object should be
> already allocated and initialized separately before reaching this
> point.
>
> We rely on the standard dev->parent chain to access the rust driver
> object from the fwctl callbacks.

(I will go for a thorough review soon, but for now a quick drive-by comment.)

IIUC, you are saying that the user is supposed to use the private data of the
parent device in fwctl callbacks. Let's not make this a design choice please.
Instead, allow the user pass in separate private data for the fwctl device as
well.

This serves the purpose of clear ownership and lifetime of the data. E.g. the
fwctl device does not necessarily exist as long as the parent device is bound.

It is a good thing if driver authors are forced to take a decision about which
object owns the data and what's the scope of the data.