linux-kernel - Re: [PATCH v5 02/40] drm/gpuvm: Allow VAs to hold soft reference to BOs

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: <aCysKgGyq5eOXW87@cassiopeiae>
Date: Tue, 20 May 2025 18:22:02 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Rob Clark <robdclark@...il.com>
Cc: dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
	linux-arm-msm@...r.kernel.org, Connor Abbott <cwabbott0@...il.com>,
	Rob Clark <robdclark@...omium.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 02/40] drm/gpuvm: Allow VAs to hold soft reference to
 BOs

On Tue, May 20, 2025 at 08:54:53AM -0700, Rob Clark wrote:
> On Tue, May 20, 2025 at 12:40 AM Danilo Krummrich <dakr@...nel.org> wrote:
> > On Mon, May 19, 2025 at 10:51:25AM -0700, Rob Clark wrote:
> > It invalidates the whole design and makes a lot of functions fundamentally
> > invalid to call, which is well demonstrated by all the WARN_ON() calls this
> > patch attempts to add.
> 
> I think of it more as adding a different mode of operation.  One
> where, perhaps some functions of gpuvm are not available, but that is
> fine because they are also unneeded in that mode of operation.  Hence
> the WARN_ON()s to make that clear.

This isn't a different mode of operation. You're breaking the design and
internal guarantees and validity the code relies on. And as a consequence you
have to disable the functions that are obviously broken by scattering it with
WARN_ON() calls.

And for the remaining code that is not disabled we'd have entirely new
requirements on the guarantees the caller must provide in terms of reference
counts.

This is as if I'd try to promote a car with a broken engine control unit and
would tell you "It's just in a different mode of operation, where driving isn't
supported, but you can still heat the cabin and power the radio with the
engine.", hoping that the broken engine control unit has no other side effects.

Sorry, as much as I'd like to help and unblock you, I don't buy it.