On Thu, 12 Dec 2024 17:00:09 +0100 Sebastian Sewior <bigeasy@xxxxxxxxxxxxx> wrote: > > The lockig of the raw_spinlock_t has irqsave. Correct. But not because > it expects to be called in interrupt disabled context or an actual > interrupt. It was _irq() but got changed because it is used in the early > init code and would unconditionally enable interrupts which should > remain disabled. > Yep, I understand that. My point was that because it does it this way, it should also work in hard interrupt context. But it doesn't! Looking deeper, I do not think this is safe from interrupt context! I'm looking at the rt_mutex_slowlock_block(): if (waiter == rt_mutex_top_waiter(lock)) owner = rt_mutex_owner(lock); else owner = NULL; raw_spin_unlock_irq(&lock->wait_lock); if (!owner || !rtmutex_spin_on_owner(lock, waiter, owner)) rt_mutex_schedule(); If we take an interrupt right after the raw_spin_unlock_irq() and then do a trylock on an rt_mutex in the interrupt and it gets the lock. The task is now both blocked on a lock and also holding a lock that's later in the chain. I'm not sure the PI logic can handle such a case. That is, we have in the chain of the task: lock A (blocked-waiting-for-lock) -> lock B (taken in interrupt) If another task blocks on B, it will reverse order the lock logic. It will see the owner is the task, but the task is blocked on A, the PI logic assumes that for such a case, the lock order would be: B -> A But this is not the case. I'm not sure what would happen here, but it is definitely out of scope of the requirements of the PI logic and thus, trylock must also not be used in hard interrupt context. -- Steve
