[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACMswuMd18=nhvLK2Tw3H84GnDPnhuS_YRNFEDZ5T4B5DJQtBQ@mail.gmail.com>
Date: Wed, 9 Nov 2022 01:18:05 +0800
From: Dennis Dai <dzy.0424thu@...il.com>
To: Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...gle.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: "baijiaju1990@...il.com" <baijiaju1990@...il.com>
Subject: nvme driver: possible missing `unregister_irq`
Hi all,
I was inspecting the rust nvme driver [1] and would like know if the following
code contains a missing unregister or I missed anything
// nvme.rs:180, in NvmeDevice::setup_io_queues
admin_queue.register_irq(pci_dev)?;
// nvme.rs:186, in NvmeDevice::setup_io_queues
let q_depth = core::cmp::min(...).try_into()?;
// nvme.rs:190, in NvmeDevice::setup_io_queues
let tagset = mq::TagSet::try_new(...)?; //TODO: 1 or 3 on
demand, depending on polling enabled
Line 186 and 190 could abort the execution of
NvmeDevice::setup_io_queues without calling `unregister_irq`.
In the end this could result in an `request_threaded_irq` without a
pairing `free_irq` on failure.
Or is the job done by Rust by auto dropping?
Thank you very much!
[1] https://github.com/metaspace/rust-linux/commit/d88c3744d6cbdf11767e08bad56cbfb67c4c96d0
Powered by blists - more mailing lists