The series is separated from [1] to show the independency and compare
potential use cases easier.  This is the revocable core part.  Use cases
are in other series.

The 1st patch introduces the revocable which is an implementation of ideas
from the talk [2].

The 2nd and 3rd patches add test cases for revocable in Kunit and selftest.

[1] https://lore.kernel.org/chrome-platform/20251016054204.1523139-1-tzungbi@kernel.org
[2] https://lpc.events/event/17/contributions/1627/

v7:
- Rebase onto next-20260115.

v6: https://lore.kernel.org/chrome-platform/20251106152330.11733-1-tzungbi@kernel.org
- Rebase onto next-20251106.
- Separate revocable core and use cases.

v5: https://lore.kernel.org/chrome-platform/20251016054204.1523139-1-tzungbi@kernel.org
- Rebase onto next-20251015.
- Add more context about the PoC.
- Support multiple revocable providers in the PoC.

v4: https://lore.kernel.org/chrome-platform/20250923075302.591026-1-tzungbi@kernel.org
- Rebase onto next-20250922.
- Remove the 5th patch from v3.
- Add fops replacement PoC in 5th - 7th patches.

v3: https://lore.kernel.org/chrome-platform/20250912081718.3827390-1-tzungbi@kernel.org
- Rebase onto https://lore.kernel.org/chrome-platform/20250828083601.856083-1-tzungbi@kernel.org
  and next-20250912.
- The 4th patch changed accordingly.

v2: https://lore.kernel.org/chrome-platform/20250820081645.847919-1-tzungbi@kernel.org
- Rename "ref_proxy" -> "revocable".
- Add test cases in Kunit and selftest.

v1: https://lore.kernel.org/chrome-platform/20250814091020.1302888-1-tzungbi@kernel.org

Tzung-Bi Shih (3):
  revocable: Revocable resource management
  revocable: Add Kunit test cases
  selftests: revocable: Add kselftest cases

 .../driver-api/driver-model/index.rst         |   1 +
 .../driver-api/driver-model/revocable.rst     | 152 +++++++++++
 MAINTAINERS                                   |   9 +
 drivers/base/Kconfig                          |   8 +
 drivers/base/Makefile                         |   5 +-
 drivers/base/revocable.c                      | 242 ++++++++++++++++++
 drivers/base/revocable_test.c                 | 139 ++++++++++
 include/linux/revocable.h                     |  69 +++++
 tools/testing/selftests/Makefile              |   1 +
 .../selftests/drivers/base/revocable/Makefile |   7 +
 .../drivers/base/revocable/revocable_test.c   | 136 ++++++++++
 .../drivers/base/revocable/test-revocable.sh  |  39 +++
 .../base/revocable/test_modules/Makefile      |  10 +
 .../revocable/test_modules/revocable_test.c   | 195 ++++++++++++++
 14 files changed, 1012 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/driver-api/driver-model/revocable.rst
 create mode 100644 drivers/base/revocable.c
 create mode 100644 drivers/base/revocable_test.c
 create mode 100644 include/linux/revocable.h
 create mode 100644 tools/testing/selftests/drivers/base/revocable/Makefile
 create mode 100644 tools/testing/selftests/drivers/base/revocable/revocable_test.c
 create mode 100755 tools/testing/selftests/drivers/base/revocable/test-revocable.sh
 create mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/Makefile
 create mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/revocable_test.c

-- 
2.52.0.457.g6b5491de43-goog

On Fri, Jan 16, 2026 at 08:02:32AM +0000, Tzung-Bi Shih wrote:
> The series is separated from [1] to show the independency and compare
> potential use cases easier.  This is the revocable core part.  Use cases
> are in other series.
> 
> The 1st patch introduces the revocable which is an implementation of ideas
> from the talk [2].
> 
> The 2nd and 3rd patches add test cases for revocable in Kunit and selftest.
> 
> [1] https://lore.kernel.org/chrome-platform/20251016054204.1523139-1-tzungbi@kernel.org
> [2] https://lpc.events/event/17/contributions/1627/
> 
> v7:
> - Rebase onto next-20260115.

Thanks for sticking with this, I've queued this up in the driver-core
testing branch for now, thanks!

greg k-h

On Fri, Jan 16, 2026 at 04:17:29PM +0100, Greg KH wrote:
> On Fri, Jan 16, 2026 at 08:02:32AM +0000, Tzung-Bi Shih wrote:
> > The series is separated from [1] to show the independency and compare
> > potential use cases easier.  This is the revocable core part.  Use cases
> > are in other series.
> > 
> > The 1st patch introduces the revocable which is an implementation of ideas
> > from the talk [2].
> > 
> > The 2nd and 3rd patches add test cases for revocable in Kunit and selftest.
> > 
> > [1] https://lore.kernel.org/chrome-platform/20251016054204.1523139-1-tzungbi@kernel.org
> > [2] https://lpc.events/event/17/contributions/1627/
> > 
> > v7:
> > - Rebase onto next-20260115.
> 
> Thanks for sticking with this, I've queued this up in the driver-core
> testing branch for now, thanks!

I'd like to see this being successfully used before we merge it. There's
now one patch series for the GPIO subsystem, which I think is a very
good test case. Bartosz is already reviewing it, and there's a
performance issue that needs to be investigated and addressed.

As discussed during LPC, the UAF issue in the CrOS EC that this series
was initially supposed to fix is best solved with reference counting and
refactoring of the CrOS EC driver framework. The revocable mechanism
isn't the right solution for races between device removal and userspace
access.

-- 
Regards,

Laurent Pinchart

On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:
> The revocable mechanism isn't the right solution for races between device
> removal and userspace access.

I think you have to differenciate, as it depends on the resource:

If the resource is a device resource (e.g. MMIO resource regions) that must not
be held by the driver after its bound device has been unbound, you have to
revoke the resource from the driver, i.e. you can't just fix it with a reference
count.

Effectively, that's what devres does, it releases the resource when the device
is unbound. Revocable takes care of avoiding a UAF of a subsequent access.

We subsystems that invented subsystem specific implementations for a revocable
mechanism for exactly those cases.

For instance, there is drm_dev_enter() drm_dev_exit() and drm_dev_unplug() which
ultimately does the same things as DRM specific implementation.

If the resource is not a device resource, then revocable is clearly not the
correct solution however.

On Fri, Jan 16, 2026 at 05:16:58PM +0100, Danilo Krummrich wrote:
> On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:
> > The revocable mechanism isn't the right solution for races between device
> > removal and userspace access.
> 
> I think you have to differenciate, as it depends on the resource:
> 
> If the resource is a device resource (e.g. MMIO resource regions) that must not
> be held by the driver after its bound device has been unbound, you have to
> revoke the resource from the driver, i.e. you can't just fix it with a reference
> count.

The C code doesn't really work like that, it works on sync teardown
flows. If you want to write correct C code you need to think about all
the concurrency the driver has and ensure that removal undoes it

I think Laurent is referring to the lack of a sync unregister for
fops.

In this series patches 13-16 are all fops related callbacks.

#17 kind of looks like a cancel_work_sync() is missing (ie what is
preventing this work func from running after the module unloads?)

#19 is all sysfs stuff, and sysfs already has a sync unregister, so
maybe these SRCU's can never fail?

Jason

On Fri Jan 16, 2026 at 5:52 PM CET, Jason Gunthorpe wrote:
> The C code doesn't really work like that, it works on sync teardown
> flows. If you want to write correct C code you need to think about all
> the concurrency the driver has and ensure that removal undoes it

Again, it depends: Sometimes a synchronized teardown is not possible. Iff a
synchronized teardown is not possible by design, this is where revocable is
useful instead.

However, a synchronized teardown should of course always be preferred.

And just to clarify, since you said "the C code": The Rust code follows exactly
the the same principle, prefer synchronized teardown whenever possible.

(The only difference with Rust is that we can always guard device resources and
iff synchronized teardown is ensured through the type system the guard becomes
zero-cost for accesses.)