diff options
| author | Karl Mehltretter <kmehltretter@gmail.com> | 2026-08-21 04:53:27 +0200 |
|---|---|---|
| committer | Jarkko Sakkinen <jarkko@kernel.org> | 2026-09-12 00:43:45 +0300 |
| commit | 2725ab3f5ad1c5f375c7c9fee4af02a9b138f701 (patch) | |
| tree | 8157496009561789cb076d824486caff06a49092 /tools/perf/scripts/python/stackcollapse.py | |
| parent | 827751b699b79a6e569983359c02dce67f81b94c (diff) | |
| download | linux-next-2725ab3f5ad1c5f375c7c9fee4af02a9b138f701.tar.gz linux-next-2725ab3f5ad1c5f375c7c9fee4af02a9b138f701.zip | |
keys: fix lost wakeup when reaping a dead key type
clear_bit() is atomic with respect to the word it modifies, but it is
an unordered operation: it implies no memory barrier on either side
(Documentation/atomic_bitops.txt).
key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit()
and calls wake_up_bit() after reaping a dead key type. wake_up_bit()
uses a lockless waitqueue check and requires a full barrier after the
clear.
The existing smp_mb() is before clear_bit(), so nothing orders the clear
against that check. The GC can see an empty waitqueue while
unregister_key_type() still sees the bit set. The final wakeup is then
lost, leaving module unload stuck in wait_on_bit().
Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE
semantics, so the completed GC work stays ordered before the clear, and
its smp_mb__after_atomic() orders the clear before the waitqueue check.
Fixes: 0c061b5707ab ("KEYS: Correctly destroy key payloads when their keytype is removed")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
