On Fri, Dec 13, 2024 at 9:43 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > 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. If hard-irq acquired rt_mutex B (spin_lock or spin_trylock doesn't change the above analysis), the task won't schedule and it has to release this rt_mutex B before reenabling irq. The irqrestore without releasing the lock is a bug regardless. What's the concern then? That PI may see an odd order of locks for this task ? but it cannot do anything about it anyway, since the task won't schedule. And before irq handler is over the B will be released and everything will look normal again.
