Revert "revocable: Revocable resource management"

Revert "revocable: Revocable resource management"

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/
Link: https://lore.kernel.org/all/aXT45B6vLf9R3Pbf@hovoldconsulting.com/
Link: https://lore.kernel.org/all/20260129143733.45618-1-tzungbi@kernel.org/
Link: https://lore.kernel.org/all/aXobzoeooJqxMkEj@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260204142849.22055-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>