From: "Gary Guo" <gary@garyguo.net>
To: "Danilo Krummrich" <dakr@kernel.org>, "Gary Guo" <gary@garyguo.net>
Cc: <bhelgaas@google.com>, <kwilczynski@kernel.org>,
<aliceryhl@google.com>, <daniel.almeida@collabora.com>,
<ojeda@kernel.org>, <boqun@kernel.org>,
<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
<a.hindborg@kernel.org>, <tmgross@umich.edu>, <tamird@kernel.org>,
<acourbot@nvidia.com>, <work@onurozkan.dev>,
<jhubbard@nvidia.com>, <ttabi@nvidia.com>, <apopple@nvidia.com>,
<ecourtney@nvidia.com>, <shashanks@nvidia.com>, <zhiw@nvidia.com>,
<driver-core@lists.linux.dev>, <linux-pci@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/5] rust: pci: resolve IRQ in vector() and embed IrqRequest in IrqVector
Date: Wed, 12 Aug 2026 19:09:41 +0100 [thread overview]
Message-ID: <DKN60QB0522T.1IRNS63F2RMXG@garyguo.net> (raw)
In-Reply-To: <DKN5HGXO6M7E.1SL8IATHZFUK1@kernel.org>
On Wed Aug 12, 2026 at 6:44 PM BST, Danilo Krummrich wrote:
> On Wed Aug 12, 2026 at 6:38 PM CEST, Gary Guo wrote:
>> On Wed Aug 12, 2026 at 12:39 AM BST, Danilo Krummrich wrote:
>>> pub fn vector(&self, index: usize) -> Result<IrqVector<'_>> {
>>> if index >= self.count.get() {
>>> return Err(EINVAL);
>>> }
>>>
>>> - // SAFETY: `index` is within bounds of this registration's allocation, and `self.dev` is
>>> - // the device it was allocated from.
>>> - Ok(unsafe { IrqVector::new(self.dev, self, index as u32) })
>>> + // SAFETY: `self.dev.as_raw()` is a valid pointer to a `struct pci_dev`.
>>> + let irq = unsafe { bindings::pci_irq_vector(self.dev.as_raw(), index as u32) };
>>> + if irq < 0 {
>>> + return Err(Error::from_errno(irq));
>>> + }
>>
>> Correct me if I'm wrong, but I believe that it's impossible for `pci_irq_vector`
>> once we have allocated vector and the index is in bounds. (If that's not the
>> case, we should ideally fix that instead.)
>
> You are correct, as of now it is unreachable with the index check above.
>
>> So I think we should just `.expect()` on the error in `Into`.
>
> I don't agree with the conclusion; I don't want this code to rely on an
> implementation detail of pci_irq_vector(), which (even though unlikely) could
> theoretically change.
I think this is expected use pattern of `pci_irq_vector`. Many C code don't
check the return code at all. If we want to mirror what C code do, we can also
just drop this error code check and rely on `irq as u32` below doing the correct
thing.
For both this and the EINVAL case for patch 1, my reasoning is that if the error
is never going to happen, then the code shouldn't be written as if it does, as
it will only add confusion to people reading the code.
I view these essentially as invariants, just not spelled out because it's
written in another language. In this case, basically you can say that
`pci_irq_vector(dev, index)` being successful is an invariant of
`IrqVectorRegistration` type.
>
> If we want to remove the redundancy, then we could maybe drop the index check
> above.
I think the index check should stay.
Best,
Gary
>
> (I also prefer IrqVector to be a new type over IrqRequest, as it also guarantees
> type wise that a valid IrqVector will always transform into a valid IrqRequest.)
next prev parent reply other threads:[~2026-08-12 18:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 23:39 [PATCH v2 0/5] Rework PCI IRQ vector code Danilo Krummrich
2026-08-11 23:39 ` [PATCH v2 1/5] rust: pci: convert IrqVectorRegistration to a lifetime-managed owning type Danilo Krummrich
2026-08-11 23:52 ` sashiko-bot
2026-08-12 16:26 ` Gary Guo
2026-08-12 17:37 ` Danilo Krummrich
2026-08-12 18:11 ` Gary Guo
2026-08-12 18:47 ` Danilo Krummrich
2026-08-12 19:01 ` Gary Guo
2026-08-12 19:57 ` Danilo Krummrich
2026-08-11 23:39 ` [PATCH v2 2/5] rust: pci: resolve IRQ in vector() and embed IrqRequest in IrqVector Danilo Krummrich
2026-08-11 23:48 ` sashiko-bot
2026-08-12 16:38 ` Gary Guo
2026-08-12 17:44 ` Danilo Krummrich
2026-08-12 18:09 ` Gary Guo [this message]
2026-08-12 19:31 ` Danilo Krummrich
2026-08-11 23:39 ` [PATCH v2 3/5] rust: pci: remove request_irq() and request_threaded_irq() from Device Danilo Krummrich
2026-08-11 23:47 ` sashiko-bot
2026-08-11 23:39 ` [PATCH v2 4/5] PCI: Add pci_irq_type() to query the allocated interrupt type Danilo Krummrich
2026-08-11 23:44 ` sashiko-bot
2026-08-11 23:39 ` [PATCH v2 5/5] rust: pci: expose " Danilo Krummrich
2026-08-11 23:46 ` sashiko-bot
2026-08-12 16:44 ` Gary Guo
2026-08-12 17:57 ` Danilo Krummrich
2026-08-12 18:16 ` Gary Guo
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=DKN60QB0522T.1IRNS63F2RMXG@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=ecourtney@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shashanks@nvidia.com \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=work@onurozkan.dev \
--cc=zhiw@nvidia.com \
/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