Re: [PATCH v6 1/3] revocable: Revocable resource management

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Nov 6, 2025 at 4:23 PM CET, Tzung-Bi Shih wrote:
> +Revocable vs. Device-Managed (devm) Resources
> +=============================================
> +
> +It's important to understand the distinction between a standard
> +device-managed (devm) resource and a resource managed by a revocable provider.
> +
> +The key difference is their lifetime:
> +
> +*   A **devm resource** is tied to the lifetime of the device.  It is
> +    automatically freed when the device is unbound.
> +*   A **revocable provider** persists as long as there are active references
> +    to it from consumer handles.
> +
> +This means that a revocable provider can outlive the device that created
> +it.  This is a deliberate design feature, allowing consumers to hold a
> +reference to a resource even after the underlying device has been removed,

This seems wrong, the consumer does not hold a reference to the encapsulated
resource, it holds a reference to the revocable object itself.

The resource itself may be revoked at any point of time -- usually by devres,
but can be anything.

This makes revocable an independent synchronization primitive -- which admittedly
is mainly designed for (device) resources. Yet, it's independent.

In comparison, devres manages the lifetime of a resource, while ignoring if
there are active users or not.

Hence, I think the description needs some adjustments, as it makes it sounds as
if they're the same thing with different lifetime patterns, while they're
fundamentally different components.

I'd rather explain how revocable can complement devres.

> +/**
> + * DOC: Overview
> + *
> + * Some resources can be removed asynchronously, for example, resources
> + * provided by a hot-pluggable device like USB.  When holding a reference
> + * to such a resource, it's possible for the resource to be removed and
> + * its memory freed, leading to use-after-free errors on subsequent access.
> + *
> + * The "revocable" mechanism addresses this by establishing a weak reference
> + * to a resource that might be freed at any time.  It allows a resource
> + * consumer to safely attempt to access the resource, guaranteeing that the
> + * access is valid for the duration of its use, or it fails safely if the
> + * resource has already been revoked.

Here you start the documentation with _how_ revocable can be used, but I'd
rather start with explaining what it is, i.e. explain that it is a
synchronization primitive manages the access to an object that can
asynchronously be revoked, etc.

I'd move the example use-case below that.

The code itself LGTM, hence with the above addressed,

Acked-by: Danilo Krummrich <dakr@kernel.org>