linux-kernel - Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST

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: <F72EBB64-BB07-4FFA-85C9-3EDE9AEE3C48@nvidia.com>
Date: Thu, 18 Dec 2025 22:44:39 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Timur Tabi <ttabi@...dia.com>
CC: Alexandre Courbot <acourbot@...dia.com>, "dakr@...nel.org"
	<dakr@...nel.org>, "lossin@...nel.org" <lossin@...nel.org>,
	"a.hindborg@...nel.org" <a.hindborg@...nel.org>, "boqun.feng@...il.com"
	<boqun.feng@...il.com>, "ojeda@...nel.org" <ojeda@...nel.org>,
	"simona@...ll.ch" <simona@...ll.ch>, "tmgross@...ch.edu" <tmgross@...ch.edu>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
	"bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>, Eliot Courtney
	<ecourtney@...dia.com>, "aliceryhl@...gle.com" <aliceryhl@...gle.com>,
	"kwilczynski@...nel.org" <kwilczynski@...nel.org>, "bhelgaas@...gle.com"
	<bhelgaas@...gle.com>, "gary@...yguo.net" <gary@...yguo.net>, Alistair Popple
	<apopple@...dia.com>
Subject: Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP
 command GSP upon unloading



> On Dec 18, 2025, at 5:33 PM, Timur Tabi <ttabi@...dia.com> wrote:
> 
> On Thu, 2025-12-18 at 22:27 +0900, Alexandre Courbot wrote:
>>>> +    loop {
>>>> +        match cmdq.receive_msg::<UnloadingGuestDriverReply>(Delta::from_secs(5)) {
>>>> +            Ok(resp) => return Ok(resp),
>>>> +            Err(ERANGE) => continue,
>>>> +            Err(e) => return Err(e),
>>>> +        }
>>> 
>>> This outer loop can go on infinitely, lets bound it?
>>> 
>>> Either outer timeout or bounded number of tries. Bounded tries better since it has inner
>>> timeout.
>> 
>> Yes. And what we really want is a more generic way to do this, because
>> this pattern occurs with several commands so far (and more to come).
> 
> Isn't the real problem that we are polling for a specific message, when all message should be
> handled asynchronously as events, like Nouveau does?
> 
>          Err(ERANGE) => continue,
> 
> This effectively throws out all other messages, including errors and anything else important.
> 

Indeed, for that we need Interrupts. For the rest of the patterns where we need the message synchronously, we should bound this. Hanging in the driver is unacceptable.

Interrupts are almost here now, considering we/others have upstreamed all the required patches for Rust interrupt support.