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

[Jarkko Sakkinen]

On Wed, Oct 28, 2026 at 01:58:19AM +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 increase: 5%
> - aarch64: chunk max: 235 ms, total increase: 6%
> 
> Tests were performed using a laptop with AMD 4650U Zen 2 archtitecture CPU.
							   ~~~~~~~~~~~~~
							   architecture

> 
> Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>

Sashiko: https://sashiko.dev/#/patchset/20261027235820.2002072-1-jarkko%40kernel.org

Br, Jarkko