Messages in this thread | | | Subject | Re: [PATCH] locking/rtmutex: Flush the plug before entering the slowpath. | From | Crystal Wood <> | Date | Tue, 18 Apr 2023 18:43:48 -0500 |
| |
On Tue, 2023-04-18 at 17:18 +0200, Sebastian Andrzej Siewior wrote: > On 2023-03-22 17:27:21 [+0100], To Thomas Gleixner wrote: > > blk_flush_plug() is invoked on schedule() to flush out the IO progress > > that has been made so far so that it is globally visible. This is > > important to avoid deadlocks because a lock owner can wait for IO. > > Therefore the IO must be first flushed before a thread can block on a > > lock. > > > > The plug flush routine can acquire a sleeping lock which is contended. > > Blocking on a lock requires an assignment to task_struct::pi_blocked_on. > > If blk_flush_plug() is invoked from the slow path on schedule() then the > > variable is already set and will be overwritten by the lock in > > blk_flush_plug(). > > Therefore it is needed to invoke blk_flush_plug() (and block on > > potential locks in the process) before the blocking on the actual lock. > > > > Invoke blk_flush_plug() before blocking on a sleeping lock. The > > PREEMPT_RT only sleeping locks (spinlock_t and rwlock_t) are excluded > > because their slow path does not invoke blk_flush_plug(). > > > > Fixes: e17ba59b7e8e1 ("locking/rtmutex: Guard regular sleeping locks > > specific functions") > > Reported-by: Crystal Wood <swood@redhat.com> > > Link: > > https://lore.kernel.org/4b4ab374d3e24e6ea8df5cadc4297619a6d945af.camel@redhat.com > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > polite ping.
Sorry, got distracted. It does appear to make the asserts go away but I ran into other possibly related stalls when running rteval -- but if I remove both the asserts and your patch it hangs in a different way, so I need to investigate some more.
-Crystal
| |