[PATCH v2 5/6] KEYS: Replace assoc_array with rhashtable
Jarkko Sakkinen
jarkko at kernel.org
Sat Oct 24 04:58:13 UTC 2026
I'll just run through three issues that I forgot to update for this
patch set version. I think it was good because probably these could
use some feedback.
On Fri, Oct 23, 2026 at 03:09:25PM +0300, Jarkko Sakkinen wrote:
> + WARN_ON(rhashtable_remove_fast(&links->ht, &link->node,
> + keyring_link_params));
> + list_del_rcu(&link->list);
> + WRITE_ONCE(links->nr, links->nr - 1);
> + call_rcu(&link->rcu, keyring_link_free_rcu);
keyring_remove_link() is called by __key_unlink() and keyring_gc(),
which are infallible operations.
At minimum this should be changed as:
if (WARN_ON(rhashtable_remove_fast(/* ... */))
return;
/* ... */
Alternatively, keyring_remove_link() could be fallible operation,
and leave that decision up to the callers.
> + WARN_ON(rhashtable_replace_fast(&links->ht, &old->node,
> + &link->node,
> + keyring_link_params));
> + list_replace_rcu(&old->list, &link->list);
> + call_rcu(&old->rcu, keyring_link_free_rcu);
__key_link() is called by __key_instantiate_and_link(), key_link(),
key_move(), construct_alloc_key() and key_reject_and_link() i.e.,
by majority fallible functions.
Are all of these call sites such that if __key_link() was a fallible
operation it would be impossible roll back, or is this something that
could be addressed better?
> + WARN_ON(rhashtable_remove_fast(&keyring_index_locked(keyring)->ht,
> + &link->node,
> + keyring_link_params));
> + call_rcu(&link->rcu, keyring_link_free_rcu);
__key_link_end() goes along the lines of keyring_link_remove().
However these are decided I will remove keyring_link_remove(). There's
enough symbols to get confused already, it has only two call sites and
frankly I'd just want to see its contents open-coded in those sites.
And it makes the level symmetric with __key_link_end().
keyring_link_remove() is type of slop that needs to be wiped away
constantly from any LLM sourced code, at least in my experience as models
tend to build on top of that design, and soon you have a nest.
Br, Jarkko
More information about the Linux-security-module-archive
mailing list