Re: [PATCH v2] KEYS: key_garbage_collector(): process in chunks

[Jarkko Sakkinen <jarkko@kernel.org>]

On Wed, Oct 28, 2026 at 04:53:04AM +0200, Jarkko Sakkinen wrote:
> key_garbage_collector() has a design that is not resistant enough for
> workqueue lockups. The duration scales up relative to the number of items
> in the serial tree, which causes a reoccuring theme of being guilty of
> causing workqueue lockups.
> 
> Resolve the problem by processing in chunks:
> 
> 1. Declare a static variable key_gc_work, which owns the garbage collection
>    in-flight state, and key_schedule_gc_work() for re-scheduling the work.
> 2. Define KEY_GC_CHUNK_SIZE, set to 1024 keys, as the bound for the number
>    of items scanned and destroyed.
> 3. Define KEY_GC_DESTROYING to mark resume to destruction without repeating
>    the RCU grace period. Drain the graveyard before advancing key-type
>    reaping.
> 4. Define KEY_GC_REAP_REQUESTED for preserving full-pass requests across
>    the continuations.
> 
> The following test was performed:
> 
> 1. Add 499995 "unused" keys.
> 2. Add 499994 "expiring" keys i.e., keys with expiration times.
> 3. Clear the first keyring.
> 4. Wait for the timeouts expire from the second.
> 
> When tested with QEMU using x86-64 and aarch64 (emulated) architectures the
> elapsed the results were the following:
> 
> - x86-64: chunk max: 125 ms, total time increase: 5%
> - aarch64: chunk max: 235 ms, total time increase: 6%
> 
> Tests were performed using a laptop with AMD 4650U (Zen 2 uarch) CPU.
> 
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

The big picture here is that e.g., [1] might be a good idea (or might
not) but it would be a mistake to apply the patch before the data flow
overall has some sanity in it.

And with, I think, somewhat pretty modest changes the state has been
put in a nice box :-) Much better shovelling position I'd say.

[1] https://lore.kernel.org/keyrings/20261026031219.2627968-1-jarkko@kernel.org/

Br, Jarkko