linux-kernel - Re: [PATCH v2] rust: pci: Allocate and manage PCI interrupt vectors

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: <e9f4711a-04fd-48d2-ab13-03ea94eeac5d@nvidia.com>
Date: Wed, 8 Oct 2025 14:11:55 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 nouveau@...ts.freedesktop.org, rust-for-linux@...r.kernel.org,
 linux-pci@...r.kernel.org, acourbot@...dia.com,
 Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, John Hubbard <jhubbard@...dia.com>,
 Timur Tabi <ttabi@...dia.com>, joel@...lfernandes.org,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Wilczyński <kwilczynski@...nel.org>
Subject: Re: [PATCH v2] rust: pci: Allocate and manage PCI interrupt vectors



On 10/5/2025 8:56 AM, Danilo Krummrich wrote:
>> +        let ret = unsafe {
>> +            bindings::pci_alloc_irq_vectors(dev.as_raw(), min_vecs, max_vecs, irq_types.as_raw())
>> +        };
>> +
>> +        to_result(ret)?;
>> +        let count = ret as u32;
>> +
>> +        // SAFETY: Vectors are 0-based, so valid indices are [0, count-1].
>> +        // pci_alloc_irq_vectors guarantees count >= min_vecs > 0, so count - 1 is valid.
>> This is a justification why the range makes sense (which makes sense to keep as
> a separate comment), but it doesn't justify the safety requirement of
> IrqVector::new().

Is the following better? Or did you have some other reasoning you want me to
mention? The safety comes from the fact that both start/end vector indices and
everything in between are valid.

// SAFETY:
// - `pci_alloc_irq_vectors` returns the number of allocated vectors on success.
// - Vectors are 0-based, so valid indices are [0, count-1].
// - `pci_alloc_irq_vectors` guarantees count >= min_vecs > 0, so both 0 and
//    count - 1 are valid IRQ vector indices for device `dev`.
// - Vector indices are contiguous, so all vectors in [0, count-1] are valid.

Thanks.