linux-kernel - Re: [PATCH] locking/rtmutex: Flush the plug before entering the slowpath.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e3f9c399a6ef26a145a9fcc53201bbd98d9428ee.camel@redhat.com>
Date:   Tue, 18 Apr 2023 18:43:48 -0500
From:   Crystal Wood <swood@...hat.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Cc:     John Keeping <john@...anate.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH] locking/rtmutex: Flush the plug before entering the
 slowpath.

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@...hat.com>
> > Link:
> > https://lore.kernel.org/4b4ab374d3e24e6ea8df5cadc4297619a6d945af.camel@redhat.com
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.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