linux-kernel - Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

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: <20260126170720.GN1134360@nvidia.com>
Date: Mon, 26 Jan 2026 13:07:20 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Johan Hovold <johan@...nel.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
	Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
	Shuah Khan <shuah@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>, linux-doc@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

On Mon, Jan 26, 2026 at 05:08:20PM +0100, Danilo Krummrich wrote:
> On Mon Jan 26, 2026 at 1:07 AM CET, Jason Gunthorpe wrote:
> > That's the whole issue with DRM right there - allowing driver code to
> > run after the driver has unregistered from the subsystem is
> > *dangerous* and creates all these bugs.
> 
> Unfortunately, it is necessary (at least to a certain extend) in DRM. I think
> there is space for improvements, but I don't think we can get rid of this
> entirely, especially on the KMS side AFAIK.

>From what I saw alot of the issue with DRM was how it works the fops,
instead of the core subsytem managing the fops and calling the driver,
the driver managed its own fops and called back to the core.

Sure, the issues may be very hard to fix in existing code, but I find
it hard to swallow the idea that a subsystem couldn't own all the
fops/etc and guard every driver callback with a lock to generate the
right kind of fence..

> > IMHO since rust has the Device<Bound> stuff the revocable should have used
> > rwsem, because the expectation should be that the majority uses access, not
> > try_access.
> 
> Yes, the majority of uses is access(), not try_access(); not sure if rwsem is
> the better solution though.

rwsem is much faster on destroy and somewhat slower on read. Which
sounds to match the use case here. Ie you wouldn't need to do special
effort to bundle the synchronize_srcu()

Jason