linux-kernel - Re: [RFC PATCH 0/3] gpu: nova-core: add basic timer subdevice implementation

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] [day] [month] [year] [list]

Message-ID: <20250228185534.GH39591@nvidia.com>
Date: Fri, 28 Feb 2025 14:55:34 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Boqun Feng <boqun.feng@...il.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Alexandre Courbot <acourbot@...dia.com>,
	Dave Airlie <airlied@...il.com>, Gary Guo <gary@...yguo.net>,
	Joel Fernandes <joel@...lfernandes.org>,
	John Hubbard <jhubbard@...dia.com>, Ben Skeggs <bskeggs@...dia.com>,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	paulmck@...nel.org
Subject: Re: [RFC PATCH 0/3] gpu: nova-core: add basic timer subdevice
 implementation

On Thu, Feb 27, 2025 at 11:40:53PM +0100, Danilo Krummrich wrote:
> On Thu, Feb 27, 2025 at 06:00:13PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> > > 
> > > Most of the cases, it should be naturally achieved, because you already
> > > bind the objects into your module or driver, otherwise they would be
> > > already cancelled and freed. 
> > 
> > I'm getting the feeling you can probably naturally achieve the
> > required destructors, but I think Danillo is concerned that since it
> > isn't *mandatory* it isn't safe/sound.
> 
> Of course you can "naturally" achieve the required destructors, I even explained
> that in [1]. :-)
> 
> And yes, for *device resources* it is unsound if we do not ensure that the
> device resource is actually dropped at device unbind.

Why not do a runtime validation then?

It would be easy to have an atomic counting how many devres objects
are still alive.

Have remove() WARN_ON to the atomic and a dumb sleep loop until it is 0.

Properly written drives never hit it. Buggy drivers will throw a
warning and otherwise function safely.

I'm thinking the standard design pattern is a problem that is too
complex for static analysis to solve.

Jason