linux-kernel - Re: [PATCH 3/3] Revert "revocable: Revocable resource management"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFX09S7L40VL.1HVC33VXNDDBW@kernel.org>
Date: Sat, 24 Jan 2026 18:46:11 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Johan Hovold" <johan@...nel.org>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Rafael J . Wysocki"
 <rafael@...nel.org>, "Tzung-Bi Shih" <tzungbi@...nel.org>, "Bartosz
 Golaszewski" <bartosz.golaszewski@....qualcomm.com>, "Linus Walleij"
 <linusw@...nel.org>, "Jonathan Corbet" <corbet@....net>, "Shuah Khan"
 <shuah@...nel.org>, "Laurent Pinchart" <laurent.pinchart@...asonboard.com>,
 "Wolfram Sang" <wsa+renesas@...g-engineering.com>, "Simona Vetter"
 <simona.vetter@...ll.ch>, "Dan Williams" <dan.j.williams@...el.com>, "Jason
 Gunthorpe" <jgg@...dia.com>, <linux-doc@...r.kernel.org>,
 <linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] Revert "revocable: Revocable resource management"

On Sat Jan 24, 2026 at 6:05 PM CET, Johan Hovold wrote:
> 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:
>
> 	struct revocable {
> 		struct revocable_provider *rp;
> 		int idx;
> 	};
>
> 	void *revocable_try_access(struct revocable *rev)
> 	{
> 		struct revocable_provider *rp = rev->rp;
>
> 		rev->idx = srcu_read_lock(&rp->srcu);
> 		return srcu_dereference(rp->res, &rp->srcu);
> 	}
>
> 	void revocable_withdraw_access(struct revocable *rev)
> 	{
> 		struct revocable_provider *rp = rev->rp;
>
> 		srcu_read_unlock(&rp->srcu, rev->idx);
> 	}
>
> Multiple threads may 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.

I think the easiest fix would be to just return the index to the caller and let
the corresponding revocable macro accessors handle it, such that it is still
transparent to the user.