On 2024-12-12 10:48:09 [-0500], Steven Rostedt wrote: > On Thu, 12 Dec 2024 16:35:06 +0100 > Sebastian Sewior <bigeasy@xxxxxxxxxxxxx> wrote: > > > 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… > > Looking at the unlock code, it and the slowtrylock() appears to use > raw_spin_lock_irqsave(). Hence it expects that it can be called from > irq disabled context. If it can be used in interrupt disabled context, > I don't see why it wouldn't work in actual interrupt context. trylock records current as owner. This task did not attempt to acquire the lock. The lock part will might PI-boost it via task_blocks_on_rt_mutex() - this random task. That task might already wait on one lock and now this gets added to the mix. This could be okay since a task can own multiple locks, wait on one and get PI boosted on any of those at any time. However, we never used that way. 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. > -- Steve Sebastian
