From: kernel@dakr.org
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Lyude Paul" <lyude@redhat.com>,
rust-for-linux@vger.kernel.org,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Maíra Canal" <mairacanal@riseup.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] rust/faux: Add missing parent argument to Registration::new()
Date: Wed, 26 Feb 2025 10:05:48 +0100 [thread overview]
Message-ID: <ea2466c4d250ff953b3be9602a3671fb@dakr.org> (raw)
In-Reply-To: <CAH5fLghwkK4S12eMUm3bgMXvYMNf_1Gi9ws9q-53OZPdB+QHQA@mail.gmail.com>
On 2025-02-26 09:38, Alice Ryhl wrote:
> On Tue, Feb 25, 2025 at 10:31 PM Lyude Paul <lyude@redhat.com> wrote:
>>
>> A little late in the review of the faux device interface, we added the
>> ability to specify a parent device when creating new faux devices -
>> but
>> this never got ported over to the rust bindings. So, let's add the
>> missing
>> argument now so we don't have to convert other users later down the
>> line.
>>
>> Signed-off-by: Lyude Paul <lyude@redhat.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>> rust/kernel/faux.rs | 10 ++++++++--
>> samples/rust/rust_driver_faux.rs | 2 +-
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/rust/kernel/faux.rs b/rust/kernel/faux.rs
>> index 41751403cd868..ae99ea3d114ef 100644
>> --- a/rust/kernel/faux.rs
>> +++ b/rust/kernel/faux.rs
>> @@ -23,11 +23,17 @@
>>
>> impl Registration {
>> /// Create and register a new faux device with the given name.
>> - pub fn new(name: &CStr) -> Result<Self> {
>> + pub fn new(name: &CStr, parent: Option<&device::Device>) ->
>> Result<Self> {
>> // SAFETY:
>> // - `name` is copied by this function into its own storage
>> // - `faux_ops` is safe to leave NULL according to the C API
>> - let dev = unsafe {
>> bindings::faux_device_create(name.as_char_ptr(), null_mut(), null())
>> };
>> + let dev = unsafe {
>> + bindings::faux_device_create(
>> + name.as_char_ptr(),
>> + parent.map_or(null_mut(), |p| p.as_raw()),
>> + null(),
>
> This function signature only requires that `parent` is valid for the
> duration of this call to `new`, but `faux_device_create` stashes a
> pointer without touching the refcount. How do you ensure that the
> `parent` pointer does not become dangling?
I was wondering the same, but it seems that the subsequent device_add()
call takes care of that:
https://elixir.bootlin.com/linux/v6.14-rc3/source/drivers/base/core.c#L3588
device_del() drops the reference.
This makes device->parent only valid for the duration between
faux_device_create() and faux_device_remove().
But this detail shouldn’t be relevant for this API.
WARNING: multiple messages have this Message-ID (diff)
From: kernel@dakr.org
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Lyude Paul" <lyude@redhat.com>,
rust-for-linux@vger.kernel.org,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Maíra Canal" <mairacanal@riseup.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] rust/faux: Add missing parent argument to Registration::new()
Date: Wed, 26 Feb 2025 10:03:42 +0100 [thread overview]
Message-ID: <ea2466c4d250ff953b3be9602a3671fb@dakr.org> (raw)
Message-ID: <20250226090342.J142eqstLp0nreEJSUvOohqjOxOR3zrZydbUZO2It7w@z> (raw)
In-Reply-To: <CAH5fLghwkK4S12eMUm3bgMXvYMNf_1Gi9ws9q-53OZPdB+QHQA@mail.gmail.com>
On 2025-02-26 09:38, Alice Ryhl wrote:
> On Tue, Feb 25, 2025 at 10:31 PM Lyude Paul <lyude@redhat.com> wrote:
>>
>> A little late in the review of the faux device interface, we added the
>> ability to specify a parent device when creating new faux devices -
>> but
>> this never got ported over to the rust bindings. So, let's add the
>> missing
>> argument now so we don't have to convert other users later down the
>> line.
>>
>> Signed-off-by: Lyude Paul <lyude@redhat.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>> rust/kernel/faux.rs | 10 ++++++++--
>> samples/rust/rust_driver_faux.rs | 2 +-
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/rust/kernel/faux.rs b/rust/kernel/faux.rs
>> index 41751403cd868..ae99ea3d114ef 100644
>> --- a/rust/kernel/faux.rs
>> +++ b/rust/kernel/faux.rs
>> @@ -23,11 +23,17 @@
>>
>> impl Registration {
>> /// Create and register a new faux device with the given name.
>> - pub fn new(name: &CStr) -> Result<Self> {
>> + pub fn new(name: &CStr, parent: Option<&device::Device>) ->
>> Result<Self> {
>> // SAFETY:
>> // - `name` is copied by this function into its own storage
>> // - `faux_ops` is safe to leave NULL according to the C API
>> - let dev = unsafe {
>> bindings::faux_device_create(name.as_char_ptr(), null_mut(), null())
>> };
>> + let dev = unsafe {
>> + bindings::faux_device_create(
>> + name.as_char_ptr(),
>> + parent.map_or(null_mut(), |p| p.as_raw()),
>> + null(),
>
> This function signature only requires that `parent` is valid for the
> duration of this call to `new`, but `faux_device_create` stashes a
> pointer without touching the refcount. How do you ensure that the
> `parent` pointer does not become dangling?
I was wondering the same, but it seems that the subsequent device_add()
call takes care of that:
https://elixir.bootlin.com/linux/v6.14-rc3/source/drivers/base/core.c#L3588
device_del() drops the reference.
This makes device->parent only valid for the duration between
faux_device_create() and faux_device_remove().
But this detail shouldn’t be relevant for this API.
next prev parent reply other threads:[~2025-02-26 9:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250225213112.872264-1-lyude@redhat.com>
2025-02-25 21:29 ` [PATCH 1/2] rust/faux: Drop #[repr(transparent)] from faux::Registration Lyude Paul
2025-02-25 22:07 ` Danilo Krummrich
2025-02-26 8:39 ` Alice Ryhl
2025-02-26 12:59 ` Fiona Behrens
2025-02-25 21:29 ` [PATCH 2/2] rust/faux: Add missing parent argument to Registration::new() Lyude Paul
2025-02-25 22:07 ` Danilo Krummrich
2025-02-26 8:38 ` Alice Ryhl
2025-02-26 9:05 ` kernel [this message]
2025-02-26 9:03 ` kernel
2025-02-26 9:23 ` Alice Ryhl
2025-02-26 9:42 ` Danilo Krummrich
2025-02-26 9:51 ` Alice Ryhl
2025-02-26 9:58 ` Greg KH
2025-02-26 10:39 ` Danilo Krummrich
2025-02-26 11:01 ` Greg KH
2025-02-26 10:01 ` Greg Kroah-Hartman
2025-02-26 16:51 ` Lyude Paul
2025-02-26 19:31 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea2466c4d250ff953b3be9602a3671fb@dakr.org \
--to=kernel@dakr.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=mairacanal@riseup.net \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox