Re: [BUG] gfs2: sleeping lock in gfs2_quota_init() with preempt disabled on PREEMPT_RT

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-08-12 14:39:29 [+0900], Yunseong Kim wrote:
> While testing with PREEMPT_RT enabled, I encountered a potential issue in
> gfs2_quota_init() where preemption is disabled via bit_spin_lock(), but a
> subsequent call eventually reaches a sleepable lock.
> 
> Below is the simplified call flow:
> [PREEMPT_RT]
…
> At the moment, two possible approaches come to mind:
> 
> 1. Avoid using the bit-spinlock in this path entirely
>  - Rework the bucket protection so we do not call into code that may sleep
>    while preemption is disabled.
>  - no sleeping while preemption-disabled.
>  - May require reworking bucket protection/race re-check logic.

So this would add 4096 spinlocks for RT. Given that those a bit bigger
than the other ones, it will use a bit more than 16KiB of memory.
Maybe fewer could be used assuming lock sharing is fine here but I
haven't checked the code

> 2. Replace the inner lock with a non-sleeping primitive
>  - (e.g., use a raw_spinlock_t for lockref->lock) so it can be taken while
>    preemption is disabled.
>  - Since lockref does not currently support raw_spinlock_t, this would require
>    additional rework of the lockref structure.
>  - Minimal structural change; avoids sleeping in the problematic context.

This is something. 
Looking at the layout of struct lockref USE_CMPXCHG_LOCKREF can only
work if the spinlock is the raw_spinlock_t without lockdep. So it
expects the lock to be unlocked and does a 64bit cmpxchg() to inc/ dec
the counter that follows.

I was confused why lockref_mark_dead() works for dcache given that the
lock is not released outside of lockref.c except for
lockref_put_or_lock(). But then I noticed d_lock.

So making the lock raw_spinlock_t breaks the few lockref_put_or_lock()
users. The impact on dcache is huge and I noticed some waitqueue
handling which would break. So there is that.

Based on this I think it should be handled somehow within gfs2.

> I can help test patches for this on both PREEMPT_RT and NON-RT kernels.
> 
> 
> Thanks,
> Yunseong Kim

Sebastian