On Wed, Jan 17, 2024 at 11:44:55PM +0100, Thomas Gleixner wrote: > On Tue, Jan 16 2024 at 04:37, Leonardo Bras wrote: > > With PREEMPT_RT enabled, a spin_lock_irqsave() becomes a possibly sleeping > > spin_lock(), without preempt_disable() or irq_disable(). > > > > This allows a task T1 to get preempted or interrupted while holding the > > port->lock. If the preempting task T2 need the lock, spin_lock() code > > will schedule T1 back until it finishes using the lock, and then go back to > > T2. > > > > There is an issue if a T1 holding port->lock is interrupted by an > > IRQ, and this IRQ handler needs to get port->lock for writting (printk): > > spin_lock() code will try to reschedule the interrupt handler, which is in > > atomic context, causing a BUG() for trying to reschedule/sleep in atomic > > context. > > > > So for the case (PREEMPT_RT && in_atomic()) try to get the lock, and if it > > fails proceed anyway, just like it's done in oops_in_progress case. > > That's just blantantly wrong. The locks are really only to be ignored > for the oops case, but not for regular printk. I agree, but the alternative was to have a BUG() due to scheduling in atomic context. This would only ignore the lock if it was already taken anyway. That being said, I agree it is not the best solution for the issue, and just sent this in the RFC in order to get feedback on what could be done. > > I assume that this is not against the latest RT kernel as that should > not have that problem at all. I am based on torvalds/linux at master branch, so maybe I am missing some RT-specific patches. Which tree do you recommend me testing? > > Thanks, > > tglx > Thank you! Leo
