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 <[email protected]>
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/[email protected]/ Br, Jarkko
