From: sashiko-bot@kernel.org
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
"David Howells" <dhowells@redhat.com>
Cc: "Eric Biggers" <ebiggers@kernel.org>,
"Mimi Zohar" <zohar@linux.ibm.com>,
syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
"Eric Snowberg" <eric.snowberg@oracle.com>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>,
"open list:KEYS/KEYRINGS" <keyrings@vger.kernel.org>
Subject: Re: [PATCH v7] KEYS: key_garbage_collector(): process in chunks
Date: Fri, 30 Oct 2026 20:38:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-191485@kernel.org> (raw)
In-Reply-To: <20261030202457.3058665-1-jarkko@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KEYS: key_put() sets KEY_GC_KEY_EXPIRED via key_schedule_gc(0)
--
commit 46ff4f9d21b46f71b2432aa577bc3594d1df5791
Author: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: key_garbage_collector(): process in chunks
This commit updates key_garbage_collector() and key_gc_unused_keys() to scan
the key serial tree and destroy unused keys in bounded chunks of 64 keys. It
also introduces key_schedule_gc_work() and KEY_GC_REAP_REQUESTED to preserve
garbage collection requests across chunked workqueue continuations.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd-test.git/tree/package/keygcbench
> diff --git a/security/keys/gc.c b/security/keys/gc.c
> index eda445f815d47..ea2efde5f33fd 100644
> --- a/security/keys/gc.c
> +++ b/security/keys/gc.c
[ ... ]
> @@ -44,6 +56,21 @@ struct key_type key_type_dead = {
> .name = ".dead",
> };
>
> +/*
> + * Schedule a new GC pass or re-schedule an ongoing GC pass.
> + */
> +void key_schedule_gc_work(bool expired)
> +{
> + unsigned long flags = BIT(KEY_GC_REAP_REQUESTED);
> +
> + if (expired)
> + flags |= BIT(KEY_GC_KEY_EXPIRED);
> +
> + /* Publish all request flags together, after the caller's updates. */
> + set_mask_bits(&key_gc_flags, 0, flags);
> + schedule_work(&key_gc_work.work);
> +}
> +
> /*
> * Schedule a garbage collection run.
> * - time precision isn't particularly important
> @@ -57,7 +84,8 @@ void key_schedule_gc(time64_t gc_at)
>
> if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags)) {
> kdebug("IMMEDIATE");
> - schedule_work(&key_gc_work);
> + /* Catch expirations that became due during the scan. */
> + key_schedule_gc_work(true);
> } else if (gc_at < key_gc_next_run) {
[ ... ]
> diff --git a/security/keys/key.c b/security/keys/key.c
> index a438c4508595d..ab3d3a70705af 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -661,7 +661,7 @@ void key_put(struct key *key)
> }
> /* Mark key as safe for GC after key->user done. */
> clear_bit_unlock(KEY_FLAG_USER_ALIVE, &key->flags);
> - schedule_work(&key_gc_work);
> + key_schedule_gc(0);
> }
> }
> }
[Severity: Medium]
When key_put() drops the final reference on a key
(refcount_dec_and_test(&key->usage)), calling key_schedule_gc(0) causes
gc_at <= now to evaluate as true and calls key_schedule_gc_work(true), which
sets KEY_GC_KEY_EXPIRED in key_gc_flags:
key_put()
key_schedule_gc(0)
key_schedule_gc_work(true)
set_mask_bits(&key_gc_flags, 0,
BIT(KEY_GC_REAP_REQUESTED) | BIT(KEY_GC_KEY_EXPIRED))
In key_garbage_collector(), KEY_GC_KEY_EXPIRED sets KEY_GC_REAPING_LINKS in
gc->state:
if (test_and_clear_bit(KEY_GC_KEY_EXPIRED, &key_gc_flags))
gc->state |= KEY_GC_REAPING_LINKS;
...
if ((gc->state & KEY_GC_REAPING_LINKS) ||
unlikely(gc->state & KEY_GC_REAPING_DEAD_2)) {
if (key->type == &key_type_keyring)
goto found_keyring;
}
Because every keyring link holds a reference on key->usage, a key reaching a
usage count of zero has no remaining links in any keyring and only needs to be
removed from key_serial_tree and freed via the graveyard list. With
KEY_GC_KEY_EXPIRED set on every final key_put(), key_garbage_collector() will
instead drop key_serial_lock on every keyring in key_serial_tree and run
keyring_gc() across all keyrings in the system whenever any unreferenced key
is freed. In addition, if key_gc_unused_keys() frees a keyring that held links
to other keys, keyring_destroy() will call key_put() and set
KEY_GC_KEY_EXPIRED again for the next pass.
Similarly, in key_schedule_gc(), if gc_at > now while KEY_GC_REAP_KEYTYPE is
set, key_schedule_gc_work(true) will set KEY_GC_KEY_EXPIRED even though the
expiration time has not been reached.
Should key_put() call key_schedule_gc_work(false) directly instead of
key_schedule_gc(0), and should key_schedule_gc() pass gc_at <= now to
key_schedule_gc_work()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030202457.3058665-1-jarkko@kernel.org?part=1
next prev parent reply other threads:[~2026-10-30 20:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 20:24 [PATCH v7] KEYS: key_garbage_collector(): process in chunks Jarkko Sakkinen
2026-10-30 20:38 ` sashiko-bot [this message]
2026-10-30 20:44 ` 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=sashiko-outbox-191485@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiggers@kernel.org \
--cc=eric.snowberg@oracle.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=serge@hallyn.com \
--cc=syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com \
--cc=zohar@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox