All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: "Boqun Feng" <boqun.feng@gmail.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczy´nski" <kwilczynski@kernel.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 3/6] rust: irq: add support for non-threaded IRQs and handlers
Date: Mon, 23 Jun 2025 21:27:43 +0200	[thread overview]
Message-ID: <DAU5SDZWTB21.2S8F08BVX1ZE1@kernel.org> (raw)
In-Reply-To: <DAU5QLRJBYMS.2OQ83W31ETX07@kernel.org>

On Mon Jun 23, 2025 at 9:25 PM CEST, Benno Lossin wrote:
> On Mon Jun 23, 2025 at 7:31 PM CEST, Boqun Feng wrote:
>> On Mon, Jun 23, 2025 at 05:26:14PM +0200, Benno Lossin wrote:
>>> On Mon Jun 23, 2025 at 5:10 PM CEST, Alice Ryhl wrote:
>>> > On Mon, Jun 9, 2025 at 12:47 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>> >> On Sun, Jun 08, 2025 at 07:51:08PM -0300, Daniel Almeida wrote:
>>> >> > +        dev: &'a Device<Bound>,
>>> >> > +        irq: u32,
>>> >> > +        flags: Flags,
>>> >> > +        name: &'static CStr,
>>> >> > +        handler: T,
>>> >> > +    ) -> impl PinInit<Self, Error> + 'a {
>>> >> > +        let closure = move |slot: *mut Self| {
>>> >> > +            // SAFETY: The slot passed to pin initializer is valid for writing.
>>> >> > +            unsafe {
>>> >> > +                slot.write(Self {
>>> >> > +                    inner: Devres::new(
>>> >> > +                        dev,
>>> >> > +                        RegistrationInner {
>>> >> > +                            irq,
>>> >> > +                            cookie: slot.cast(),
>>> >> > +                        },
>>> >> > +                        GFP_KERNEL,
>>> >> > +                    )?,
>>> >> > +                    handler,
>>> >> > +                    _pin: PhantomPinned,
>>> >> > +                })
>>> >> > +            };
>>> >> > +
>>> >> > +            // SAFETY:
>>> >> > +            // - The callbacks are valid for use with request_irq.
>>> >> > +            // - If this succeeds, the slot is guaranteed to be valid until the
>>> >> > +            // destructor of Self runs, which will deregister the callbacks
>>> >> > +            // before the memory location becomes invalid.
>>> >> > +            let res = to_result(unsafe {
>>> >> > +                bindings::request_irq(
>>> >> > +                    irq,
>>> >> > +                    Some(handle_irq_callback::<T>),
>>> >> > +                    flags.into_inner() as usize,
>>> >> > +                    name.as_char_ptr(),
>>> >> > +                    slot.cast(),
>>> >> > +                )
>>> >> > +            });
>>> >> > +
>>> >> > +            if res.is_err() {
>>> >> > +                // SAFETY: We are returning an error, so we can destroy the slot.
>>> >> > +                unsafe { core::ptr::drop_in_place(&raw mut (*slot).handler) };
>>> >> > +            }
>>> >> > +
>>> >> > +            res
>>> >> > +        };
>>> >> > +
>>> >> > +        // SAFETY:
>>> >> > +        // - if this returns Ok, then every field of `slot` is fully
>>> >> > +        // initialized.
>>> >> > +        // - if this returns an error, then the slot does not need to remain
>>> >> > +        // valid.
>>> >> > +        unsafe { pin_init_from_closure(closure) }
>>> >>
>>> >> Can't we use try_pin_init!() instead, move request_irq() into the initializer of
>>> >> RegistrationInner and initialize inner last?
>>> >
>>> > We need a pointer to the entire struct when calling
>>> > bindings::request_irq. I'm not sure this allows you to easily get one?
>>> > I don't think using container_of! here is worth it.
>>> 
>>> There is the `&this in` syntax (`this` is of type `NonNull<Self>`):
>>> 
>>>     try_pin_init!(&this in Self {
>>>         inner: Devres::new(
>>>             dev,
>>>             RegistrationInner {
>>>                 irq,
>>>                 cookie: this.as_ptr().cast(),
>>>             },
>>>             GFP_KERNEL,
>>>         )?,
>>>         handler,
>>>         _pin: {
>>>             to_result(unsafe {
>>>                 bindings::request_irq(
>>>                     irq,
>>>                     Some(handle_irq_callback::<T>),
>>>                     flags.into_inner() as usize,
>>>                     name.as_char_ptr(),
>>>                     slot.as_ptr().cast(),
>>
>> this is "this" instead of "slot", right?
>>
>>>                 )
>>>             })?;
>>>             PhantomPinned
>>>         },
>>>     })
>>> 
>>> Last time around, I also asked this question and you replied with that
>>> we need to abort the initializer when `request_irq` returns false and
>>> avoid running `Self::drop` (thus we can't do it using `pin_chain`).
>>> 
>>> I asked what we could do instead and you mentioned the `_: {}`
>>> initializers and those would indeed solve it, but we can abuse the
>>> `_pin` field for that :)
>>> 
>>
>> Hmm.. but if request_irq() fails, aren't we going to call `drop` on
>> `inner`, which drops the `Devres` which will eventually call
>> `RegistrationInner::drop()`? And that's a `free_irq()` without
>> `request_irq()` succeeded.
>
> That is indeed correct :(
>
> But hold on, we aren't allowed to forget the `Devres`, it's a pinned
> type and thus the pin guarantee is that it must be dropped before the
> underlying memory is freed. So the current version is unsound.

Ah oops, already had the devres improvements in mind, this version uses
the non-pinned devres, which when not dropped will leak an `Arc` in the
`DevresInner`... Which also isn't desired.

---
Cheers,
Benno

  reply	other threads:[~2025-06-23 19:27 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-08 22:51 [PATCH v4 0/6] rust: add support for request_irq Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 1/6] rust: irq: add irq module Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 2/6] rust: irq: add flags module Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 3/6] rust: irq: add support for non-threaded IRQs and handlers Daniel Almeida
2025-06-09 11:47   ` Danilo Krummrich
2025-06-23 15:10     ` Alice Ryhl
2025-06-23 15:23       ` Danilo Krummrich
2025-06-23 15:25         ` Alice Ryhl
2025-06-23 15:26       ` Benno Lossin
2025-06-23 17:31         ` Boqun Feng
2025-06-23 19:18           ` Boqun Feng
2025-06-23 19:28             ` Benno Lossin
2025-06-24 12:31               ` Daniel Almeida
2025-06-24 12:46                 ` Benno Lossin
2025-06-24 13:50                   ` Alice Ryhl
2025-06-24 14:33                     ` Boqun Feng
2025-06-24 14:42                       ` Boqun Feng
2025-06-24 14:56                         ` Danilo Krummrich
2025-06-24 15:17                       ` Benno Lossin
2025-06-23 19:25           ` Benno Lossin
2025-06-23 19:27             ` Benno Lossin [this message]
2025-06-08 22:51 ` [PATCH v4 4/6] rust: irq: add support for threaded " Daniel Almeida
2025-06-09 12:27   ` Danilo Krummrich
2025-06-09 16:24     ` Daniel Almeida
2025-06-09 18:13       ` Danilo Krummrich
2025-06-09 18:30         ` Miguel Ojeda
2025-06-16 13:33         ` Alice Ryhl
2025-06-16 13:43           ` Danilo Krummrich
2025-06-16 17:49             ` Danilo Krummrich
2025-06-22 20:53         ` Benno Lossin
2025-06-16 13:48       ` Daniel Almeida
2025-06-16 15:45         ` Danilo Krummrich
2025-06-16 13:52       ` Daniel Almeida
2025-06-08 22:51 ` [PATCH v4 5/6] rust: platform: add irq accessors Daniel Almeida
2025-06-09 12:51   ` Danilo Krummrich
2025-06-08 22:51 ` [PATCH v4 6/6] rust: pci: " Daniel Almeida
2025-06-09 12:53   ` Danilo Krummrich
2025-06-09 23:22   ` kernel test robot

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=DAU5SDZWTB21.2S8F08BVX1ZE1@kernel.org \
    --to=lossin@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.