Hi Sebastian, On Mon, Feb 28, 2022 at 03:29:32PM +0100, Sebastian Andrzej Siewior wrote: > > > Could you please post a lockdep report so I can take a look? > > > > I thought the problem with lockdep was stated by you somewhere in this thread? > > https://lore.kernel.org/lkml/YfOqsOiNfURyvFRX@xxxxxxxxxxxxx/ > > "But even then we need to find a way to move the crng init part > > (crng_fast_load()) out of the hard-IRQ." > > And Jonathan posted two related (?) splats he ran into. > > > > I may have gotten that all wrong, in which case, I'll just excise that > > part from the commit message. I'm pretty sure you want this patch > > either way, right? > > Oh, that report. So yes, I want that patch ;) > > In this case the lockdep is right. The thing that it affects only > PREEMPT_RT. > That trylock is not the thing that lockdep complains about but the > spin_lock_irqsave() within invalidate_batched_entropy(). > > Taking a spinlock_t from IRQ context is problematic for PREEMPT_RT, > correct. A spin_try_lock() is also problematic since another spin_lock() > invocation would PI-boost the wrong task (the spin_try_lock() is invoked > from an IRQ-context so the task on CPU (random task or idle) is not the > actual owner). I'm pointing this out because there was also _another_ > problem with try_lock from hard-IRQ context which was fixed in the > meantime. > > Would it work for you to update the commit message? Basically I'm fine > with the firs sentence but the remaining part is misleading. Ahh, I understand, okay. Yes, I'll change that first paragraph to incorporate your wording, as: """ Taking spinlocks from IRQ context is generally problematic for PREEMPT_RT. That is, in part, why we take trylocks instead. However, a spin_try_lock() is also problematic since another spin_lock() invocation can potentially PI-boost the wrong task, as the spin_try_lock() is invoked from an IRQ-context, so the task on CPU (random task or idle) is not the actual owner. """ Jason
