This reverts commit 62eb557580eb2177cf16c3fd2b6efadff297b29a.
The revocable implementation uses two separate abstractions, struct
revocable_provider and struct revocable, in order to store the SRCU read
lock index which must be passed unaltered to srcu_read_unlock() in the
same context when a resource is no longer needed.
With the merged revocable API, multiple threads could however share the
same struct revocable and therefore potentially overwrite the SRCU index
of another thread which can cause the SRCU synchronisation in
revocable_provider_revoke() to never complete. [1]
An example revocable conversion of the gpiolib code also turned out to
be fundamentally flawed and could lead to use-after-free. [2]
An attempt to address both issues was quickly put together and merged,
but revocable is still fundamentally broken. [3]
Specifically, the latest design relies on RCU for storing a pointer to
the revocable provider, but since the resource can be shared by value
(e.g. as in the now reverted selftests) this does not work at all and
can also lead to use-after-free:
static void revocable_provider_release(struct kref *kref)
{
struct revocable_provider *rp = container_of(kref,
struct revocable_provider, kref);
cleanup_srcu_struct(&rp->srcu);
kfree_rcu(rp, rcu);
}
void revocable_provider_revoke(struct revocable_provider __rcu **rp_ptr)
{
struct revocable_provider *rp;
rp = rcu_replace_pointer(*rp_ptr, NULL, 1);
...
kref_put(&rp->kref, revocable_provider_release);
}
int revocable_init(struct revocable_provider __rcu *_rp,
struct revocable *rev)
{
struct revocable_provider *rp;
...
scoped_guard(rcu) {
rp = rcu_dereference(_rp);
if (!rp)
return -ENODEV;
if (!kref_get_unless_zero(&rp->kref))
return -ENODEV;
}
...
}
producer:
priv->rp = revocable_provider_alloc(&priv->res);
// pass priv->rp by value to consumer
revocable_provider_revoke(&priv->rp);
consumer:
struct revocable_provider __rcu *rp = filp->private_data;
struct revocable *rev;
revocable_init(rp, &rev);
as _rp would still be non-NULL in revocable_init() regardless of whether
the producer has revoked the resource and set its pointer to NULL.
Essentially revocable still relies on having a pointer to reference
counted driver data which holds the revocable provider, which makes all
the RCU protection unnecessary along with most of the current revocable
design and implementation.
As the above shows, and as has been pointed out repeatedly elsewhere,
these kind of issues are not something that should be addressed
incrementally. [4]
Revert the revocable implementation until a redesign has been proposed
and evaluated properly.
Link: https://lore.kernel.org/all/20260124170535.11756-4-johan@kernel.org/ [1]
Link: https://lore.kernel.org/all/aXT45B6vLf9R3Pbf@hovoldconsulting.com/ [2]
Link: https://lore.kernel.org/all/20260129143733.45618-1-tzungbi@kernel.org/ [3]
Link: https://lore.kernel.org/all/aXobzoeooJqxMkEj@hovoldconsulting.com/ [4]
Signed-off-by: Johan Hovold <johan@kernel.org>
---
.../driver-api/driver-model/index.rst | 1 -
.../driver-api/driver-model/revocable.rst | 149 ------------
MAINTAINERS | 7 -
drivers/base/revocable.c | 225 ------------------
include/linux/revocable.h | 89 -------
5 files changed, 471 deletions(-)
delete mode 100644 Documentation/driver-api/driver-model/revocable.rst
delete mode 100644 drivers/base/revocable.c
delete mode 100644 include/linux/revocable.h
diff --git a/Documentation/driver-api/driver-model/index.rst b/Documentation/driver-api/driver-model/index.rst
index 8e1ee21185df..4831bdd92e5c 100644
--- a/Documentation/driver-api/driver-model/index.rst
+++ b/Documentation/driver-api/driver-model/index.rst
@@ -14,7 +14,6 @@ Driver Model
overview
platform
porting
- revocable
.. only:: subproject and html
diff --git a/Documentation/driver-api/driver-model/revocable.rst b/Documentation/driver-api/driver-model/revocable.rst
deleted file mode 100644
index 350e7faeccdc..000000000000
--- a/Documentation/driver-api/driver-model/revocable.rst
+++ /dev/null
@@ -1,149 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-==============================
-Revocable Resource Management
-==============================
-
-Overview
-========
-
-.. kernel-doc:: drivers/base/revocable.c
- :doc: Overview
-
-Revocable vs. Devres (devm)
-===========================
-
-It's important to understand the distinct roles of the Revocable and Devres,
-and how they can complement each other. They address different problems in
-resource management:
-
-* **Devres:** Primarily address **resource leaks**. The lifetime of the
- resources is tied to the lifetime of the device. The resource is
- automatically freed when the device is unbound. This cleanup happens
- irrespective of any potential active users.
-
-* **Revocable:** Primarily addresses **invalid memory access**,
- such as Use-After-Free (UAF). It's an independent synchronization
- primitive that decouples consumer access from the resource's actual
- presence. Consumers interact with a "revocable object" (an intermediary),
- not the underlying resource directly. This revocable object persists as
- long as there are active references to it from consumer handles.
-
-**Key Distinctions & How They Complement Each Other:**
-
-1. **Reference Target:** Consumers of a resource managed by the Revocable
- mechanism hold a reference to the *revocable object*, not the
- encapsulated resource itself.
-
-2. **Resource Lifetime vs. Access:** The underlying resource's lifetime is
- independent of the number of references to the revocable object. The
- resource can be freed at any point. A common scenario is the resource
- being freed by `devres` when the providing device is unbound.
-
-3. **Safe Access:** Revocable provides a safe way to attempt access. Before
- using the resource, a consumer uses the Revocable API (e.g.,
- revocable_try_access()). This function checks if the resource is still
- valid. It returns a pointer to the resource only if it hasn't been
- revoked; otherwise, it returns NULL. This prevents UAF by providing a
- clear signal that the resource is gone.
-
-4. **Complementary Usage:** `devres` and Revocable work well together.
- `devres` can handle the automatic allocation and deallocation of a
- resource tied to a device. The Revocable mechanism can be layered on top
- to provide safe access for consumers whose lifetimes might extend beyond
- the provider device's lifetime. For instance, a userspace program might
- keep a character device file open even after the physical device has been
- removed. In this case:
-
- * `devres` frees the device-specific resource upon unbinding.
- * The Revocable mechanism ensures that any subsequent operations on the
- open file handle, which attempt to access the now-freed resource,
- will fail gracefully (e.g., revocable_try_access() returns NULL)
- instead of causing a UAF.
-
-In summary, `devres` ensures resources are *released* to prevent leaks, while
-the Revocable mechanism ensures that attempts to *access* these resources are
-done safely, even if the resource has been released.
-
-API and Usage
-=============
-
-For Resource Providers
-----------------------
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_provider
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_provider_alloc
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_provider_revoke
-
-For Resource Consumers
-----------------------
-.. kernel-doc:: include/linux/revocable.h
- :identifiers: revocable
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_init
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_deinit
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_try_access
-
-.. kernel-doc:: drivers/base/revocable.c
- :identifiers: revocable_withdraw_access
-
-.. kernel-doc:: include/linux/revocable.h
- :identifiers: REVOCABLE_TRY_ACCESS_WITH
-
-Example Usage
-~~~~~~~~~~~~~
-
-.. code-block:: c
-
- void consumer_use_resource(struct revocable_provider *rp)
- {
- struct foo_resource *res;
-
- REVOCABLE_TRY_ACCESS_WITH(rp, res);
- // Always check if the resource is valid.
- if (!res) {
- pr_warn("Resource is not available\n");
- return;
- }
-
- // At this point, 'res' is guaranteed to be valid until
- // this block exits.
- do_something_with(res);
-
- } // revocable_withdraw_access() is automatically called here.
-
-.. kernel-doc:: include/linux/revocable.h
- :identifiers: REVOCABLE_TRY_ACCESS_SCOPED
-
-Example Usage
-~~~~~~~~~~~~~
-
-.. code-block:: c
-
- void consumer_use_resource(struct revocable_provider *rp)
- {
- struct foo_resource *res;
-
- REVOCABLE_TRY_ACCESS_SCOPED(rp, res) {
- // Always check if the resource is valid.
- if (!res) {
- pr_warn("Resource is not available\n");
- return;
- }
-
- // At this point, 'res' is guaranteed to be valid until
- // this block exits.
- do_something_with(res);
- }
-
- // revocable_withdraw_access() is automatically called here.
- }
diff --git a/MAINTAINERS b/MAINTAINERS
index 93c07c645c68..1c5ceccc9928 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22385,13 +22385,6 @@ F: include/uapi/linux/rseq.h
F: kernel/rseq.c
F: tools/testing/selftests/rseq/
-REVOCABLE RESOURCE MANAGEMENT
-M: Tzung-Bi Shih <tzungbi@kernel.org>
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/base/revocable.c
-F: include/linux/revocable.h
-
RFKILL
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
diff --git a/drivers/base/revocable.c b/drivers/base/revocable.c
deleted file mode 100644
index 8532ca6a371c..000000000000
--- a/drivers/base/revocable.c
+++ /dev/null
@@ -1,225 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright 2026 Google LLC
- *
- * Revocable resource management
- */
-
-#include <linux/device.h>
-#include <linux/kref.h>
-#include <linux/revocable.h>
-#include <linux/slab.h>
-#include <linux/srcu.h>
-
-/**
- * DOC: Overview
- *
- * The "revocable" mechanism is a synchronization primitive designed to manage
- * safe access to resources that can be asynchronously removed or invalidated.
- * Its primary purpose is to prevent Use-After-Free (UAF) errors when
- * interacting with resources whose lifetimes are not guaranteed to outlast
- * their consumers.
- *
- * This is particularly useful in systems where resources can disappear
- * unexpectedly, such as those provided by hot-pluggable devices like USB.
- * When a consumer holds a reference to such a resource, the underlying device
- * might be removed, causing the resource's memory to be freed. Subsequent
- * access attempts by the consumer would then lead to UAF errors.
- *
- * Revocable addresses this by providing a form of "weak reference" and a
- * controlled access method. It allows a resource consumer to safely attempt to
- * access the resource. The mechanism guarantees that any access granted is
- * valid for the duration of its use. If the resource has already been
- * revoked (i.e., freed), the access attempt will fail safely, typically by
- * returning NULL, instead of causing a crash.
- *
- * The implementation uses a provider/consumer model built on Sleepable
- * RCU (SRCU) to guarantee safe memory access:
- *
- * - A resource provider, such as a driver for a hot-pluggable device,
- * allocates a struct revocable_provider and initializes it with a pointer
- * to the resource.
- *
- * - A resource consumer that wants to access the resource allocates a
- * struct revocable which acts as a handle containing a reference to the
- * provider.
- *
- * - To access the resource, the consumer uses revocable_try_access().
- * This function enters an SRCU read-side critical section and returns
- * the pointer to the resource. If the provider has already freed the
- * resource, it returns NULL. After use, the consumer calls
- * revocable_withdraw_access() to exit the SRCU critical section. The
- * REVOCABLE_TRY_ACCESS_WITH() and REVOCABLE_TRY_ACCESS_SCOPED() are
- * convenient helpers for doing that.
- *
- * - When the provider needs to remove the resource, it calls
- * revocable_provider_revoke(). This function sets the internal resource
- * pointer to NULL and then calls synchronize_srcu() to wait for all
- * current readers to finish before the resource can be completely torn
- * down.
- */
-
-/**
- * struct revocable_provider - A handle for resource provider.
- * @srcu: The SRCU to protect the resource.
- * @res: The pointer of resource. It can point to anything.
- * @kref: The refcount for this handle.
- * @rcu: The RCU to protect pointer to itself.
- */
-struct revocable_provider {
- struct srcu_struct srcu;
- void __rcu *res;
- struct kref kref;
- struct rcu_head rcu;
-};
-
-/**
- * revocable_provider_alloc() - Allocate struct revocable_provider.
- * @res: The pointer of resource.
- *
- * This holds an initial refcount to the struct.
- *
- * Return: The pointer of struct revocable_provider. NULL on errors.
- * It enforces the caller handles the returned pointer in RCU ways.
- */
-struct revocable_provider __rcu *revocable_provider_alloc(void *res)
-{
- struct revocable_provider *rp;
-
- rp = kzalloc(sizeof(*rp), GFP_KERNEL);
- if (!rp)
- return NULL;
-
- init_srcu_struct(&rp->srcu);
- RCU_INIT_POINTER(rp->res, res);
- kref_init(&rp->kref);
-
- return (struct revocable_provider __rcu *)rp;
-}
-EXPORT_SYMBOL_GPL(revocable_provider_alloc);
-
-static void revocable_provider_release(struct kref *kref)
-{
- struct revocable_provider *rp = container_of(kref,
- struct revocable_provider, kref);
-
- cleanup_srcu_struct(&rp->srcu);
- kfree_rcu(rp, rcu);
-}
-
-/**
- * revocable_provider_revoke() - Revoke the managed resource.
- * @rp_ptr: The pointer of pointer of resource provider.
- *
- * This sets the resource `(struct revocable_provider *)->res` to NULL to
- * indicate the resource has gone.
- *
- * This drops the refcount to the resource provider. If it is the final
- * reference, revocable_provider_release() will be called to free the struct.
- *
- * It enforces the caller to pass a pointer of pointer of resource provider so
- * that it sets \*rp_ptr to NULL to prevent from keeping a dangling pointer.
- */
-void revocable_provider_revoke(struct revocable_provider __rcu **rp_ptr)
-{
- struct revocable_provider *rp;
-
- rp = rcu_replace_pointer(*rp_ptr, NULL, 1);
- if (!rp)
- return;
-
- rcu_assign_pointer(rp->res, NULL);
- synchronize_srcu(&rp->srcu);
- kref_put(&rp->kref, revocable_provider_release);
-}
-EXPORT_SYMBOL_GPL(revocable_provider_revoke);
-
-/**
- * revocable_init() - Initialize struct revocable.
- * @_rp: The pointer of resource provider.
- * @rev: The pointer of resource consumer.
- *
- * This holds a refcount to the resource provider.
- *
- * Return: 0 on success, -errno otherwise.
- */
-int revocable_init(struct revocable_provider __rcu *_rp, struct revocable *rev)
-{
- struct revocable_provider *rp;
-
- if (!_rp)
- return -ENODEV;
-
- /*
- * Enter a read-side critical section.
- *
- * This prevents kfree_rcu() from freeing the struct revocable_provider
- * memory, for the duration of this scope.
- */
- scoped_guard(rcu) {
- rp = rcu_dereference(_rp);
- if (!rp)
- /* The revocable provider has been revoked. */
- return -ENODEV;
-
- if (!kref_get_unless_zero(&rp->kref))
- /*
- * The revocable provider is releasing (i.e.,
- * revocable_provider_release() has been called).
- */
- return -ENODEV;
- }
- /* At this point, `rp` is safe to access as holding a kref of it */
-
- rev->rp = rp;
- return 0;
-}
-EXPORT_SYMBOL_GPL(revocable_init);
-
-/**
- * revocable_deinit() - Deinitialize struct revocable.
- * @rev: The pointer of struct revocable.
- *
- * This drops a refcount to the resource provider. If it is the final
- * reference, revocable_provider_release() will be called to free the struct.
- */
-void revocable_deinit(struct revocable *rev)
-{
- struct revocable_provider *rp = rev->rp;
-
- kref_put(&rp->kref, revocable_provider_release);
-}
-EXPORT_SYMBOL_GPL(revocable_deinit);
-
-/**
- * revocable_try_access() - Try to access the resource.
- * @rev: The pointer of struct revocable.
- *
- * This tries to de-reference to the resource and enters a RCU critical
- * section.
- *
- * Return: The pointer to the resource. NULL if the resource has gone.
- */
-void *revocable_try_access(struct revocable *rev) __acquires(&rev->rp->srcu)
-{
- struct revocable_provider *rp = rev->rp;
-
- rev->idx = srcu_read_lock(&rp->srcu);
- return srcu_dereference(rp->res, &rp->srcu);
-}
-EXPORT_SYMBOL_GPL(revocable_try_access);
-
-/**
- * revocable_withdraw_access() - Stop accessing to the resource.
- * @rev: The pointer of struct revocable.
- *
- * Call this function to indicate the resource is no longer used. It exits
- * the RCU critical section.
- */
-void revocable_withdraw_access(struct revocable *rev) __releases(&rev->rp->srcu)
-{
- struct revocable_provider *rp = rev->rp;
-
- srcu_read_unlock(&rp->srcu, rev->idx);
-}
-EXPORT_SYMBOL_GPL(revocable_withdraw_access);
diff --git a/include/linux/revocable.h b/include/linux/revocable.h
deleted file mode 100644
index e3d6d2c953a3..000000000000
--- a/include/linux/revocable.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright 2026 Google LLC
- */
-
-#ifndef __LINUX_REVOCABLE_H
-#define __LINUX_REVOCABLE_H
-
-#include <linux/compiler.h>
-#include <linux/cleanup.h>
-
-struct device;
-struct revocable_provider;
-
-/**
- * struct revocable - A handle for resource consumer.
- * @rp: The pointer of resource provider.
- * @idx: The index for the RCU critical section.
- */
-struct revocable {
- struct revocable_provider *rp;
- int idx;
-};
-
-struct revocable_provider __rcu *revocable_provider_alloc(void *res);
-void revocable_provider_revoke(struct revocable_provider __rcu **rp);
-
-int revocable_init(struct revocable_provider __rcu *rp, struct revocable *rev);
-void revocable_deinit(struct revocable *rev);
-void *revocable_try_access(struct revocable *rev) __acquires(&rev->rp->srcu);
-void revocable_withdraw_access(struct revocable *rev) __releases(&rev->rp->srcu);
-
-DEFINE_FREE(access_rev, struct revocable *, {
- if ((_T)->idx != -1)
- revocable_withdraw_access(_T);
- if ((_T)->rp)
- revocable_deinit(_T);
-})
-
-#define _REVOCABLE_TRY_ACCESS_WITH(_rp, _rev, _res) \
- struct revocable _rev = {.rp = NULL, .idx = -1}; \
- struct revocable *__UNIQUE_ID(name) __free(access_rev) = &_rev; \
- _res = revocable_init(_rp, &_rev) ? NULL : revocable_try_access(&_rev)
-
-/**
- * REVOCABLE_TRY_ACCESS_WITH() - A helper for accessing revocable resource
- * @_rp: The provider's ``struct revocable_provider *`` handle.
- * @_res: A pointer variable that will be assigned the resource.
- *
- * The macro simplifies the access-release cycle for consumers, ensuring that
- * corresponding revocable_withdraw_access() and revocable_deinit() are called,
- * even in the case of an early exit.
- *
- * It creates a local variable in the current scope. @_res is populated with
- * the result of revocable_try_access(). The consumer code **must** check if
- * @_res is ``NULL`` before using it. The revocable_withdraw_access() function
- * is automatically called when the scope is exited.
- *
- * Note: It shares the same issue with guard() in cleanup.h. No goto statements
- * are allowed before the helper. Otherwise, the compiler fails with
- * "jump bypasses initialization of variable with __attribute__((cleanup))".
- */
-#define REVOCABLE_TRY_ACCESS_WITH(_rp, _res) \
- _REVOCABLE_TRY_ACCESS_WITH(_rp, __UNIQUE_ID(name), _res)
-
-#define _REVOCABLE_TRY_ACCESS_SCOPED(_rp, _rev, _label, _res) \
- for (struct revocable _rev = {.rp = NULL, .idx = -1}, \
- *__UNIQUE_ID(name) __free(access_rev) = &_rev; \
- (_res = revocable_init(_rp, &_rev) ? NULL : \
- revocable_try_access(&_rev)) || true; \
- ({ goto _label; })) \
- if (0) { \
-_label: \
- break; \
- } else
-
-/**
- * REVOCABLE_TRY_ACCESS_SCOPED() - A helper for accessing revocable resource
- * @_rp: The provider's ``struct revocable_provider *`` handle.
- * @_res: A pointer variable that will be assigned the resource.
- *
- * Similar to REVOCABLE_TRY_ACCESS_WITH() but with an explicit scope from a
- * temporary ``for`` loop.
- */
-#define REVOCABLE_TRY_ACCESS_SCOPED(_rp, _res) \
- _REVOCABLE_TRY_ACCESS_SCOPED(_rp, __UNIQUE_ID(name), \
- __UNIQUE_ID(label), _res)
-
-#endif /* __LINUX_REVOCABLE_H */
--
2.52.0On Wed, Feb 04, 2026 at 03:28:49PM +0100, Johan Hovold wrote: > Specifically, the latest design relies on RCU for storing a pointer to > the revocable provider, but since the resource can be shared by value > (e.g. as in the now reverted selftests) this does not work at all and > can also lead to use-after-free: [...] > producer: > > priv->rp = revocable_provider_alloc(&priv->res); > // pass priv->rp by value to consumer > revocable_provider_revoke(&priv->rp); > > consumer: > > struct revocable_provider __rcu *rp = filp->private_data; > struct revocable *rev; > > revocable_init(rp, &rev); > > as _rp would still be non-NULL in revocable_init() regardless of whether > the producer has revoked the resource and set its pointer to NULL. You're right to point out the issue with copying the pointer of revocable provider. If a consumer stores this pointer directly, rcu_replace_pointer() in the producer's revocable_provider_revoke() will not affect the consumer's copy. I understand this concern. The intention was never for consumers to cache the pointer of revocable provider long-term. The design relies on consumers obtaining the current valid provider pointer at the point of access. In the latest GPIO transition series [5], the usage pattern has been refined to avoid locally storing the pointer of revocable provider. Instead, it's fetched from a source of truth when needed. I agree that the risks and correct usage patterns need to be much clearer. I'll update the Documentation and the selftests to explicitly highlight this limitation and demonstrate the proper way to interact with the API, avoiding the storage of the provider pointer by value in consumer contexts. > Essentially revocable still relies on having a pointer to reference > counted driver data which holds the revocable provider, which makes all > the RCU protection unnecessary along with most of the current revocable > design and implementation. (I'm assuming you are referring to the example in [6].) I'm not sure I follow your reasoning. Per my understanding: - The reference counted driver data (e.g. `gdev` in the GPIO example) is to ensure the pointer of revocable provider isn't freed. - The RCU protects the pointer value from concurrent access and updates during the revocation process [7]. These seem to address different aspects. Could you provide more context on why you see the RCU protection as redundant? [5] https://lore.kernel.org/all/20260203061059.975605-9-tzungbi@kernel.org [6] https://lore.kernel.org/all/20260203061059.975605-8-tzungbi@kernel.org [7] https://lore.kernel.org/all/20260129143733.45618-2-tzungbi@kernel.org
On Thu, Feb 05, 2026 at 08:51:19AM +0000, Tzung-Bi Shih wrote: > On Wed, Feb 04, 2026 at 03:28:49PM +0100, Johan Hovold wrote: > > Specifically, the latest design relies on RCU for storing a pointer to > > the revocable provider, but since the resource can be shared by value > > (e.g. as in the now reverted selftests) this does not work at all and > > can also lead to use-after-free: > [...] > > producer: > > > > priv->rp = revocable_provider_alloc(&priv->res); > > // pass priv->rp by value to consumer > > revocable_provider_revoke(&priv->rp); > > > > consumer: > > > > struct revocable_provider __rcu *rp = filp->private_data; > > struct revocable *rev; > > > > revocable_init(rp, &rev); > > > > as _rp would still be non-NULL in revocable_init() regardless of whether > > the producer has revoked the resource and set its pointer to NULL. > > You're right to point out the issue with copying the pointer of revocable > provider. If a consumer stores this pointer directly, rcu_replace_pointer() > in the producer's revocable_provider_revoke() will not affect the consumer's > copy. I understand this concern. > > The intention was never for consumers to cache the pointer of revocable > provider long-term. The design relies on consumers obtaining the current > valid provider pointer at the point of access. But that is not what the selftest does currently, nor is it what you need for your initial motivation for this which was miscdev where you don't have any reference counted driver data to store the pointer in. > In the latest GPIO transition series [5], the usage pattern has been refined > to avoid locally storing the pointer of revocable provider. Instead, it's > fetched from a source of truth when needed. Right, but then you don't need all the RCU stuff. And revocable becomes just a convoluted abstraction for a lock and flag (as was pointed out early on). > I agree that the risks and correct usage patterns need to be much clearer. > I'll update the Documentation and the selftests to explicitly highlight > this limitation and demonstrate the proper way to interact with the API, > avoiding the storage of the provider pointer by value in consumer contexts. And again, that's precisely why we need to evaluate the API in a non-trivial context *before* merging yet another version of this. > > Essentially revocable still relies on having a pointer to reference > > counted driver data which holds the revocable provider, which makes all > > the RCU protection unnecessary along with most of the current revocable > > design and implementation. > > (I'm assuming you are referring to the example in [6].) > > I'm not sure I follow your reasoning. Per my understanding: > - The reference counted driver data (e.g. `gdev` in the GPIO example) is to > ensure the pointer of revocable provider isn't freed. > - The RCU protects the pointer value from concurrent access and updates > during the revocation process [7]. > > These seem to address different aspects. Could you provide more context > on why you see the RCU protection as redundant? I wasn't thinking of any particular example. The struct revocable_provider is already reference counted and you don't need anything more than that as long as you only take another reference in a context where you already hold a reference. (And struct revocable_provider should be renamed struct revocable). SRCU is what prevents the race against revoke, no need for RCU. But this is designing yet another version of revocable. And that should be done out-of-tree. Johan
On Thu, Feb 05, 2026 at 03:03:21PM +0100, Johan Hovold wrote: > On Thu, Feb 05, 2026 at 08:51:19AM +0000, Tzung-Bi Shih wrote: > > On Wed, Feb 04, 2026 at 03:28:49PM +0100, Johan Hovold wrote: > > > Specifically, the latest design relies on RCU for storing a pointer to > > > the revocable provider, but since the resource can be shared by value > > > (e.g. as in the now reverted selftests) this does not work at all and > > > can also lead to use-after-free: > > [...] > > > producer: > > > > > > priv->rp = revocable_provider_alloc(&priv->res); > > > // pass priv->rp by value to consumer > > > revocable_provider_revoke(&priv->rp); > > > > > > consumer: > > > > > > struct revocable_provider __rcu *rp = filp->private_data; > > > struct revocable *rev; > > > > > > revocable_init(rp, &rev); > > > > > > as _rp would still be non-NULL in revocable_init() regardless of whether > > > the producer has revoked the resource and set its pointer to NULL. > > > > You're right to point out the issue with copying the pointer of revocable > > provider. If a consumer stores this pointer directly, rcu_replace_pointer() > > in the producer's revocable_provider_revoke() will not affect the consumer's > > copy. I understand this concern. > > > > The intention was never for consumers to cache the pointer of revocable > > provider long-term. The design relies on consumers obtaining the current > > valid provider pointer at the point of access. > > But that is not what the selftest does currently, nor is it what you Understood. As mentioned in my previous email, I'll update the selftests to reflect this. The test case somehow is simplified to setup the scenario it wants to test. > need for your initial motivation for this which was miscdev where you > don't have any reference counted driver data to store the pointer in. You're right that cros_ec_chardev.c needs to be adjusted before using the version of revocable. > > > In the latest GPIO transition series [5], the usage pattern has been refined > > to avoid locally storing the pointer of revocable provider. Instead, it's > > fetched from a source of truth when needed. > > Right, but then you don't need all the RCU stuff. And revocable becomes > just a convoluted abstraction for a lock and flag (as was pointed out > early on). I'm not sure if I understand you: as we're discussing about the stale pointer of revocable provider consumers might cache here, do you mean it doesn't need RCU at all to protect the race you reported in https://lore.kernel.org/all/aXdy-b3GOJkzGqYo@hovoldconsulting.com/? > > > I agree that the risks and correct usage patterns need to be much clearer. > > I'll update the Documentation and the selftests to explicitly highlight > > this limitation and demonstrate the proper way to interact with the API, > > avoiding the storage of the provider pointer by value in consumer contexts. > > And again, that's precisely why we need to evaluate the API in a > non-trivial context *before* merging yet another version of this. > > > > Essentially revocable still relies on having a pointer to reference > > > counted driver data which holds the revocable provider, which makes all > > > the RCU protection unnecessary along with most of the current revocable > > > design and implementation. > > > > (I'm assuming you are referring to the example in [6].) > > > > I'm not sure I follow your reasoning. Per my understanding: > > - The reference counted driver data (e.g. `gdev` in the GPIO example) is to > > ensure the pointer of revocable provider isn't freed. > > - The RCU protects the pointer value from concurrent access and updates > > during the revocation process [7]. > > > > These seem to address different aspects. Could you provide more context > > on why you see the RCU protection as redundant? > > I wasn't thinking of any particular example. > > The struct revocable_provider is already reference counted and you don't > need anything more than that as long as you only take another reference > in a context where you already hold a reference. (And struct The reference count in struct revocable_provider can't protect the race reported https://lore.kernel.org/all/aXdy-b3GOJkzGqYo@hovoldconsulting.com/. > revocable_provider should be renamed struct revocable). Probably no, struct revocable is for consumer handle. It needs somewhere to store the SRCU index. > > SRCU is what prevents the race against revoke, no need for RCU. No, without the RCU, it can't prevent the race between revoking and creating a new consumer handle. > > But this is designing yet another version of revocable. And that should > be done out-of-tree. > > Johan >
On Fri, Feb 06, 2026 at 09:14:13AM +0000, Tzung-Bi Shih wrote: > On Thu, Feb 05, 2026 at 03:03:21PM +0100, Johan Hovold wrote: > > On Thu, Feb 05, 2026 at 08:51:19AM +0000, Tzung-Bi Shih wrote: > > > You're right to point out the issue with copying the pointer of revocable > > > provider. If a consumer stores this pointer directly, rcu_replace_pointer() > > > in the producer's revocable_provider_revoke() will not affect the consumer's > > > copy. I understand this concern. > > > > > > The intention was never for consumers to cache the pointer of revocable > > > provider long-term. The design relies on consumers obtaining the current > > > valid provider pointer at the point of access. > > > > But that is not what the selftest does currently, nor is it what you > > Understood. As mentioned in my previous email, I'll update the selftests to > reflect this. The test case somehow is simplified to setup the scenario it > wants to test. > > > need for your initial motivation for this which was miscdev where you > > don't have any reference counted driver data to store the pointer in. > > You're right that cros_ec_chardev.c needs to be adjusted before using the > version of revocable. That's part of the problem here. It's unclear what problem or problems you're trying to solve. You started off with the miscdev issue, this thing morphed into something else, and now everything is just a big mess with unclear semantics and a totally confused implementation. Look, I'm not blaming you for how we ended up here. This thing should not have been merged until there was a general agreement on the usefulness of the API (which requires a problem statement and use case). The right people clearly didn't look at this in any detail since they did not expect it to be merged any time soon. And it's just unfair to you to have to redesign the whole thing under time pressure a few days before the merge window opens. New code is supposed to be ready weeks in advance, not be created and merged only days before. > > > In the latest GPIO transition series [5], the usage pattern has been refined > > > to avoid locally storing the pointer of revocable provider. Instead, it's > > > fetched from a source of truth when needed. > > > > Right, but then you don't need all the RCU stuff. And revocable becomes > > just a convoluted abstraction for a lock and flag (as was pointed out > > early on). > > I'm not sure if I understand you: as we're discussing about the stale pointer > of revocable provider consumers might cache here, do you mean it doesn't need > RCU at all to protect the race you reported in > https://lore.kernel.org/all/aXdy-b3GOJkzGqYo@hovoldconsulting.com/? Right. It's not needed. You have a refcounted structure and you can use the refcount to prevent it from going away. > > > I agree that the risks and correct usage patterns need to be much clearer. > > > I'll update the Documentation and the selftests to explicitly highlight > > > this limitation and demonstrate the proper way to interact with the API, > > > avoiding the storage of the provider pointer by value in consumer contexts. > > > > And again, that's precisely why we need to evaluate the API in a > > non-trivial context *before* merging yet another version of this. > > > > > > Essentially revocable still relies on having a pointer to reference > > > > counted driver data which holds the revocable provider, which makes all > > > > the RCU protection unnecessary along with most of the current revocable > > > > design and implementation. > > > > > > (I'm assuming you are referring to the example in [6].) > > > > > > I'm not sure I follow your reasoning. Per my understanding: > > > - The reference counted driver data (e.g. `gdev` in the GPIO example) is to > > > ensure the pointer of revocable provider isn't freed. > > > - The RCU protects the pointer value from concurrent access and updates > > > during the revocation process [7]. > > > > > > These seem to address different aspects. Could you provide more context > > > on why you see the RCU protection as redundant? > > > > I wasn't thinking of any particular example. > > > > The struct revocable_provider is already reference counted and you don't > > need anything more than that as long as you only take another reference > > in a context where you already hold a reference. (And struct > > The reference count in struct revocable_provider can't protect the race > reported https://lore.kernel.org/all/aXdy-b3GOJkzGqYo@hovoldconsulting.com/. Yes, it can. You just need to make sure you hold a reference. And redesign the API to let you do so. > > revocable_provider should be renamed struct revocable). > > Probably no, struct revocable is for consumer handle. It needs somewhere to > store the SRCU index. Yeah, you'd need to store the SRCU index elsewhere (e.g. int, typedef, context struct). > > SRCU is what prevents the race against revoke, no need for RCU. > > No, without the RCU, it can't prevent the race between revoking and creating > a new consumer handle. Yes, it can. You just need to take a step back and redesign this thing again. > > But this is designing yet another version of revocable. And that should > > be done out-of-tree. And that should be done out-of-tree. Johan
On Thu Feb 5, 2026 at 9:51 AM CET, Tzung-Bi Shih wrote:
> On Wed, Feb 04, 2026 at 03:28:49PM +0100, Johan Hovold wrote:
>> Specifically, the latest design relies on RCU for storing a pointer to
>> the revocable provider, but since the resource can be shared by value
>> (e.g. as in the now reverted selftests) this does not work at all and
>> can also lead to use-after-free:
> [...]
>> producer:
>>
>> priv->rp = revocable_provider_alloc(&priv->res);
>> // pass priv->rp by value to consumer
>> revocable_provider_revoke(&priv->rp);
>>
>> consumer:
>>
>> struct revocable_provider __rcu *rp = filp->private_data;
>> struct revocable *rev;
>>
>> revocable_init(rp, &rev);
>>
>> as _rp would still be non-NULL in revocable_init() regardless of whether
>> the producer has revoked the resource and set its pointer to NULL.
>
> You're right to point out the issue with copying the pointer of revocable
> provider. If a consumer stores this pointer directly, rcu_replace_pointer()
> in the producer's revocable_provider_revoke() will not affect the consumer's
> copy. I understand this concern.
>
> The intention was never for consumers to cache the pointer of revocable
> provider long-term. The design relies on consumers obtaining the current
> valid provider pointer at the point of access.
Yeah, I think this part is not a bug in the API, but I think revocable_init()
should be
int revocable_init(struct revocable_provider __rcu **_rp, ...)
instead of
int revocable_init(struct revocable_provider __rcu *_rp, ...)
for the same reason revocable_provider_revoke() takes a double pointer.
Otherwise this seems racy:
int revocable_init(struct revocable_provider __rcu *_rp, struct revocable *rev)
{
struct revocable_provider *rp;
if (!_rp)
return -ENODEV;
/*
* If revocable_provider_revoke() is called concurrently at this
* point, _rp is not affectd by rcu_replace_pointer().
*
* Additionally, nothing prevents a concurrent kfree_rcu() from
* freeing the revocable provider before we enter the RCU
* read-side critical section below.
*/
/*
* Enter a read-side critical section.
*
* This prevents kfree_rcu() from freeing the struct revocable_provider
* memory, for the duration of this scope.
*/
scoped_guard(rcu) {
...
}
Do I miss anything?
On Thu, Feb 05, 2026 at 12:56:47PM +0100, Danilo Krummrich wrote:
> should be
>
> int revocable_init(struct revocable_provider __rcu **_rp, ...)
>
> instead of
>
> int revocable_init(struct revocable_provider __rcu *_rp, ...)
>
> for the same reason revocable_provider_revoke() takes a double pointer.
>
> Otherwise this seems racy:
>
> int revocable_init(struct revocable_provider __rcu *_rp, struct revocable *rev)
> {
> struct revocable_provider *rp;
>
> if (!_rp)
> return -ENODEV;
>
> /*
> * If revocable_provider_revoke() is called concurrently at this
> * point, _rp is not affectd by rcu_replace_pointer().
> *
> * Additionally, nothing prevents a concurrent kfree_rcu() from
> * freeing the revocable provider before we enter the RCU
> * read-side critical section below.
> */
>
> /*
> * Enter a read-side critical section.
> *
> * This prevents kfree_rcu() from freeing the struct revocable_provider
> * memory, for the duration of this scope.
> */
> scoped_guard(rcu) {
>
> ...
> }
>
> Do I miss anything?
You're right. Will fix that.
© 2016 - 2026 Red Hat, Inc.