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: <20260128234040.GC3275574@killaraus>
Date: Thu, 29 Jan 2026 01:40:40 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>,
	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>,
	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 01:07:20PM -0400, Jason Gunthorpe wrote:
> 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..

I also don't see a real technical reason. Retrofitting the right
solution in all existing drivers wouldn't be for the faint-hearted
though, so I understand the appeal for subsystems of a quick and easy
suboptimal implementation.

> > > 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()

-- 
Regards,

Laurent Pinchart