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: <DFYNFXYTXBIW.314K249BPTA1Z@kernel.org>
Date: Mon, 26 Jan 2026 17:08:20 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Jason Gunthorpe" <jgg@...dia.com>
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 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.

(KMS is not exactly my core competence, so it would be better for someone else
to explain the details.)

> From a rust perspective I would argue you should be looking at every
> one of those try_access_with() sites in drivers as a code smell that
> says something is questionable in the driver or subsystem.

Agreed, if that is necessary it requires special attention and justification.

> In many other subsystems a driver should *never* use "try_access_with".
> Unfortunately the rust solution forces synchronize_srcu()'s anyway (which
> Bartoz rightly pointed out as an unacceptable performance issue).

I'm already working on patches that get this down to a single
synchronize_{s}rcu() call on driver unbind, which is not a hot path at all. So,
this should be fine. This should work for C code as well.

> 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.