All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Tzung-Bi Shih" <tzungbi@kernel.org>
Cc: "Benson Leung" <bleung@chromium.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <shuah@kernel.org>,
	"Dawid Niedzwiecki" <dawidn@google.com>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<chrome-platform@lists.linux.dev>,
	<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v3 1/5] revocable: Revocable resource management
Date: Fri, 12 Sep 2025 11:05:20 +0200	[thread overview]
Message-ID: <DCQP9ZJ0DFBO.3O3W57IDYN08I@kernel.org> (raw)
In-Reply-To: <20250912081718.3827390-2-tzungbi@kernel.org>

On Fri Sep 12, 2025 at 10:17 AM CEST, Tzung-Bi Shih wrote:
> +/**
> + * 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.
> + */
> +struct revocable_provider {
> +	struct srcu_struct srcu;
> +	void __rcu *res;
> +	struct kref kref;
> +};

I think a revocable provider should provide an optional revoke() callback where
users of the revocable provider can release the revoked resource.

But this can also be done as a follow-up.

> +/**
> + * 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;
> +};

I think I asked about this in the previous version (but I don't remember if
there was an answer):

In Rust we get away with a single Revocable<T> structure, but we're using RCU
instead of SRCU. It seems to me that the split between struct revocable and
struct revocable_provider is only for the SRCU index? Or is there any other
reason?

> +/**
> + * revocable_provider_free() - Free struct revocable_provider.
> + * @rp: The 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.
> + */
> +void revocable_provider_free(struct revocable_provider *rp)
> +{
> +	rcu_assign_pointer(rp->res, NULL);
> +	synchronize_srcu(&rp->srcu);
> +	kref_put(&rp->kref, revocable_provider_release);
> +}
> +EXPORT_SYMBOL_GPL(revocable_provider_free);

I think naming this "free" is a bit misleading, since what it basically does is

  (1) Revoke access to the resource.

  (2) Drop a reference count of struct revocable_provider.

In a typical application there may still be struct revocable instances that have
a reference to the provider, so we can't claim that it's freed here.

So, given that, I'd rather call this revocable_provider_revoke().

> +static void devm_revocable_provider_free(void *data)
> +{
> +	struct revocable_provider *rp = data;
> +
> +	revocable_provider_free(rp);
> +}

Same here, I'd call this devm_revocable_provider_revoke().

> +DEFINE_FREE(revocable, struct revocable *, if (_T) revocable_release(_T))
> +
> +#define _REVOCABLE(_rev, _label, _res)						\
> +	for (struct revocable *__UNIQUE_ID(name) __free(revocable) = _rev;	\
> +	     (_res = revocable_try_access(_rev)) || true; ({ goto _label; }))	\
> +		if (0) {							\
> +_label:										\
> +			break;							\
> +		} else
> +
> +#define REVOCABLE(_rev, _res) _REVOCABLE(_rev, __UNIQUE_ID(label), _res)

This is basically the same as Revocable::try_access_with() [1] in Rust, i.e.
try to access and run a closure.

Admittedly, REVOCABLE_TRY_ACCESS_WITH() is pretty verbose and I also do not have
a great idea to shorten it.

Maybe you have a good idea, otherwise I'm also fine with the current name.

Otherwise, maybe it's worth to link to the Rust Revocable API for reference?

With *_free() renamed to *_revoke(), feel free to add:

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

[1] https://rust.docs.kernel.org/kernel/revocable/struct.Revocable.html#method.try_access_with

  reply	other threads:[~2025-09-12  9:05 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-12  8:17 [PATCH v3 0/5] platform/chrome: Fix a possible UAF via revocable Tzung-Bi Shih
2025-09-12  8:17 ` [PATCH v3 1/5] revocable: Revocable resource management Tzung-Bi Shih
2025-09-12  9:05   ` Danilo Krummrich [this message]
2025-09-13 15:56     ` Tzung-Bi Shih
2025-09-12 13:27   ` Jonathan Corbet
2025-09-13 15:56     ` Tzung-Bi Shih
2025-09-17  5:24   ` Tzung-Bi Shih
2025-09-22 18:35   ` Simona Vetter
2025-09-12  8:17 ` [PATCH v3 2/5] revocable: Add Kunit test cases Tzung-Bi Shih
2025-09-12  8:17 ` [PATCH v3 3/5] selftests: revocable: Add kselftest cases Tzung-Bi Shih
2025-09-12  8:17 ` [PATCH v3 4/5] platform/chrome: Protect cros_ec_device lifecycle with revocable Tzung-Bi Shih
2025-09-12  8:17 ` [PATCH v3 5/5] platform/chrome: cros_ec_chardev: Consume cros_ec_device via revocable Tzung-Bi Shih
2025-09-12  8:30 ` [PATCH v3 0/5] platform/chrome: Fix a possible UAF " Greg Kroah-Hartman
2025-09-12  8:34   ` Danilo Krummrich
2025-09-12  9:20   ` Laurent Pinchart
2025-09-12  9:09 ` Krzysztof Kozlowski
2025-09-12  9:24   ` Bartosz Golaszewski
2025-09-12 12:49     ` Tzung-Bi Shih
2025-09-12 13:26       ` Laurent Pinchart
2025-09-12 13:39         ` Greg Kroah-Hartman
2025-09-12 13:45           ` Laurent Pinchart
2025-09-12 13:46           ` Bartosz Golaszewski
2025-09-12 13:59             ` Laurent Pinchart
2025-09-12 14:19               ` Greg Kroah-Hartman
2025-09-12 14:26                 ` Laurent Pinchart
2025-09-12 14:40                   ` Greg Kroah-Hartman
2025-09-12 14:44                     ` Bartosz Golaszewski
2025-09-12 14:54                       ` Laurent Pinchart
2025-09-12 16:22                         ` Danilo Krummrich
2025-09-13 16:17                           ` Laurent Pinchart
2025-09-22 22:43                             ` dan.j.williams
2025-09-13 15:55                         ` Tzung-Bi Shih
2025-09-13 16:14                           ` Laurent Pinchart
2025-09-23  8:20                             ` Tzung-Bi Shih
2025-09-12 14:53                     ` Laurent Pinchart
2025-09-22 15:10                   ` Jason Gunthorpe
2025-09-22 15:55                     ` Danilo Krummrich
2025-09-22 17:40                       ` Jason Gunthorpe
2025-09-22 18:42                         ` Greg Kroah-Hartman
2025-09-22 20:17                           ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DCQP9ZJ0DFBO.3O3W57IDYN08I@kernel.org \
    --to=dakr@kernel.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=corbet@lwn.net \
    --cc=dawidn@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=shuah@kernel.org \
    --cc=tzungbi@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.