Linux keyrings drop a bug-prone associative array

Linux keyrings are switching off a custom associative array that exists only for them, in favor of the kernel's existing resizable hash table, and the old implementation is being deleted along with its documentation.

Keyrings maintainer Jarkko Sakkinen posted the eleventh revision of the series on the BPF mailing list. assoc_array is more than 1,700 lines, has no test suite, and has accumulated a long bug history, which Sakkinen wrote has been made worse by large language models finding still more defects. He blamed the outcome on a shortage of in-kernel callers, maintainer time, and outside contributors. What keyrings actually need, he wrote, is a generic key-value store that performs well with sparse key sets.

The replacement, suggested by Eric Biggers and co-developed with Linus Torvalds, indexes each keyring with an rhashtable for direct lookup and an RCU-protected list for stable walks. Reading a keyring, and searching sibling keyrings, will follow list order rather than hash order: keyrings are prepended, other keys are appended, and a replacement keeps its place. Unlink, clear, revoke, and garbage collection no longer allocate memory. Teardown is deferred with sleeping RCU work because destroying the hash table may sleep. Callers such as BPF, dm-verity, and fs-verity learn whether a keyring is empty through a new helper instead of peeking at the old tree's leaf count.

The same series also carries fixes for s390's user-defined certificate store, introduced in 6.6, and Sakkinen marked them for stable. The code was dropping key references it did not own, failing to pin the user session keyring while it still used it, and not skipping keys that had already been unlinked. Automated review later questioned whether a NULL check is enough when a lookup can return an error pointer, and whether a new comment understates why the keyring read lock still matters. Sakkinen has said he does not intend to carry the s390 fixes in this series for long.