[PATCH v3 5/6] KEYS: Replace assoc_array with rhashtable

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] keys: build failure in bpf_lookup_keyring() after removing struct key.keys
--

commit 65b3c94e1ad80dd7e23ce523a687b926fdca188c
Author: Jarkko Sakkinen <jarkko at kernel.org>

KEYS: Replace assoc_array with rhashtable

This commit replaces the associative array implementation in the keyring
subsystem with rhashtable and an RCU-protected list using keyring_index and
keyring_link structures.

> diff --git a/include/linux/key.h b/include/linux/key.h
> index 20ca43f5eab1f..597131e150186 100644
> --- a/include/linux/key.h
> +++ b/include/linux/key.h

[ ... ]

> @@ -271,7 +260,7 @@ struct key {
>  		struct {
>  			/* Keyring bits */
>  			struct list_head name_link;
> -			struct assoc_array keys;
> +			struct keyring_index __rcu *index;
>  		};
>  	};

[Severity: Low]
Does removing the keys member from struct key break the build in
kernel/bpf/keys.c when both keys and bpf syscall support are enabled?

While commit 99fefa08474b ("KEYS: Introduce keyring_is_empty()") converted
dm-verity and fs-verity to use keyring_is_empty(), bpf_lookup_keyring() in
kernel/bpf/keys.c still accesses bpf_keyring->keys.nr_leaves_on_tree:

kernel/bpf/keys.c:bpf_lookup_keyring() {
	struct bpf_key *bkey;

	if (!bpf_keyring)
		return NULL;
	if (!READ_ONCE(bpf_keyring->keys.nr_leaves_on_tree) ||
	    !READ_ONCE(bpf_keyring->restrict_link))
		return NULL;
	...
}

Should bpf_lookup_keyring() be updated to call keyring_is_empty(bpf_keyring)
instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261025001105.1824178-1-jarkko@kernel.org?part=5