On Sat, Nov 07, 2026 at 09:56:01PM +0200, Jarkko Sakkinen wrote: > The keyrings subsystem is the sole user of assoc_array. It has over 1700 > lines of code, no test suite, and a long history of bugs, with LLMs now > finding more. > > This unfortunate outcome has evolved over time by large from the shortage > of in-kernel callers, time bandwidth and 3rd party contributors. > > What the keyrings subsystem needs is just a generic key-value store, which > performs well with sparse key sets. Replace assoc_array with an > rhashtable-backed keyring index and remove assoc_array from the kernel.
Sashiko: https://sashiko.dev/#/patchset/20261107195605.3929659-1-jarkko%40kernel.org Not addressing this as only one patch changed and the change was exactly: diff --git a/security/keys/keyring.c b/security/keys/keyring.c index 772fa0e35f9d..6761c6801edc 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -12,7 +12,6 @@ #include <linux/security.h> #include <linux/seq_file.h> #include <linux/err.h> -#include <linux/delay.h> #include <linux/jhash.h> #include <linux/user_namespace.h> #include <linux/nsproxy.h> @@ -101,6 +100,7 @@ static const struct rhashtable_params keyring_link_params = { .min_size = 4, .nelem_hint = 3, .automatic_shrinking = true, + .insecure_elasticity = true, }; static struct keyring_index *keyring_index_locked(const struct key *keyring) @@ -1225,12 +1225,8 @@ int __key_link_begin(struct key *keyring, if (ret < 0) goto error; - do { - ret = rhashtable_insert_fast(&links->ht, &link->node, - keyring_link_params); - if (ret == -EBUSY) - fsleep(100); - } while (ret == -EBUSY); + ret = rhashtable_insert_fast(&links->ht, &link->node, + keyring_link_params); if (ret < 0) { key_payload_reserve(keyring, keyring->datalen - KEYQUOTA_LINK_BYTES); So I don't think there are any real issue with the patch set, except I will need to rebase the commits to the latest mainline. Br, Jarkko
