On 2024-12-12 16:21:28 [+0100], Michal Hocko wrote: > On Thu 12-12-24 16:07:44, Sebastian Sewior wrote: > > But since I see in_nmi(). You can't trylock from NMI on RT. The trylock > > part is easy but unlock might need to acquire rt_mutex_base::wait_lock > > and worst case is to wake a waiter via wake_up_process(). > > Ohh, I didn't realize that. So try_lock would only be safe on > raw_spin_lock right? If NMI is one of the possible calling contexts, yes. One thing I am not 100% sure about is how "good" a spinlock_t trylock is if attempted from hardirq (on PREEMPT_RT). Obtaining the lock und unlocking is doable. The lock part will assign the "current" task as the task that owns the lock now. This task is just randomly on the CPU while the hardirq triggered. The regular spin_lock() will see this random task as the owner and might PI-boost it. This could work… Sebastian
