From: Jarkko Sakkinen <jarkko@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>
Subject: Re: [RFC PATCH 5/6] KEYS: Replace assoc_array with struct keyring_index
Date: Thu, 22 Oct 2026 17:11:43 +0300 [thread overview]
Message-ID: <atoZnxCgdrs8HNbS@kernel.org> (raw)
In-Reply-To: <atlJPhTqLaa0EEDa@kernel.org>
On Thu, Oct 22, 2026 at 02:22:43AM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 17, 2026 at 12:53:03AM +0300, Jarkko Sakkinen wrote:
> > Linux keyring would be better off without struct assoc_array given the
> > overhead caused by sole ownership of it. Linux has multiple popular choices
> > for key-value store and there is nothing special in lib/assoc_array.c that
> > would make it stand out enough to be ratiaonalize the time spent on
> > maintaining it.
> >
> > A keyring has a sparse data population, making rhashtable a plausible
> > choice. Multiple subsystems rely on it, and best of all, rhashtable has
> > dedicated maintainers.
> >
> > Replace assoc_array with struct keyring_index, allocated for a keyring on
> > its first link attempt. Initialize its ht member with rhashtable_init()
> > to store links indexed by key type, domain tag and description.
> >
> > Maintain two linked lists in the index:
> >
> > - all: enumerate committed links without retrying hash table walks when
> > the table resizes.
> > - keyrings: visit nested keyrings during recursive search without scanning
> > links to other key types.
> >
> > A key can belong to several keyrings. Represent each link with struct
> > keyring_link so it has separate hash table and list nodes and holds its
> > own key reference. Traverse the lists under RCU and defer freeing removed
> > links and dropping their key references until after a grace period.
> >
> > Assisted-by: LLM
> > Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> In addition to addressing Eric's and David's comments, I'll align the
> change with Kyle's fix (and rewrite the commit message).
This turned out not to be difficult. I just purposely had retained the
original behavior of the this patch when I rebased it yesterday until I
had my keyring PR out so could not know :-)
Kyle's fix came at really great spot because if it had came after this
feature had landed stable kernels would need a different fix than the
mainline (given that they build on top of different data structures).
Br, Jarkko
next prev parent reply other threads:[~2026-10-22 14:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 21:52 [RFC PATCH 0/6] KEYS: From assoc_array to rhashtable migration Jarkko Sakkinen
2026-10-16 21:52 ` [RFC PATCH 1/6] keys: prevent quota overflow and widen quotalen and datalen to 32 bits Jarkko Sakkinen
2026-10-17 5:28 ` Eric Biggers
2026-10-17 16:48 ` Jarkko Sakkinen
2026-10-16 21:53 ` [RFC PATCH 2/6] keys: reclaim link quota during keyring garbage collection Jarkko Sakkinen
2026-10-17 5:42 ` Eric Biggers
2026-10-17 17:06 ` Jarkko Sakkinen
2026-10-16 21:53 ` [RFC PATCH 3/6] keys: verify key identity on unlink and move Jarkko Sakkinen
2026-10-16 21:53 ` [RFC PATCH 4/6] keys: Add keyring_is_empty() for {fs,dm}-verity Jarkko Sakkinen
2026-10-16 21:53 ` [RFC PATCH 5/6] KEYS: Replace assoc_array with struct keyring_index Jarkko Sakkinen
2026-10-16 22:27 ` Jarkko Sakkinen
2026-10-18 7:08 ` Eric Biggers
2026-10-18 15:09 ` Jarkko Sakkinen
2026-10-18 15:12 ` Jarkko Sakkinen
2026-10-22 22:10 ` Jarkko Sakkinen
2026-10-19 15:02 ` David Howells
2026-10-19 15:27 ` Jarkko Sakkinen
2026-10-22 15:56 ` Jarkko Sakkinen
2026-10-21 23:22 ` Jarkko Sakkinen
2026-10-22 14:11 ` Jarkko Sakkinen [this message]
2026-10-22 23:23 ` Jarkko Sakkinen
2026-10-16 21:53 ` [RFC PATCH 6/6] lib: Remove unused assoc_array Jarkko Sakkinen
2026-10-19 21:46 ` David Howells
2026-10-19 21:50 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atoZnxCgdrs8HNbS@kernel.org \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.