On Fri, 29 Nov 2024 at 20:42, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxx> wrote:
>
> I would suggest
>
> (a) either just admit that LOCKREF doesn't work with spinlock
> statistics or debugging (which is the current situation)
>
> (b) lockref cases would be changed to not use 'spinlock_t' at all,
> but simply use 'struct raw_spinlock'.
Actually, even 'raw_spinlock' wouldn't work, we'd have to go one level
lower and use 'arch_spinlock_t'.
Both CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_LOCK_ALLOC end up messing
with raw_spinlock_t, and it's really only the very lowest
arch-specific level that is then typically the 4-byte case that we can
use atomically together with
There is possibly a third (c) alternative, though.
Right now the lockref code embeds the spinlock_t into the lockref_t.
That works fine for the "spinlock is 4 bytes in size".
But we *could* possibly turn that on its head, and say that when lock
debugging is enabled, we embed the lockref count into the
raw_spinlock_t instead (along with all the other crud we embed in
there), and then "lockref_t" simply *becomes* the spinlock (and uses
the "lock_count" that is in raw_spinlock_t).
That would be less invasive than limiting the lockref_t spinlock to
just the raw architecture spinlock, because the non-lockref spinlock
users would continue to work fine.
Not pretty, but I think it might be workable.
Linus
