linux-kernel - Re: [PATCH 0/6] locking/rtmutex: Avoid PI state recursion through sched_submit

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: <20230815161557.GK214207@hirez.programming.kicks-ass.net>
Date:   Tue, 15 Aug 2023 18:15:57 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     bigeasy@...utronix.de, tglx@...utronix.de
Cc:     linux-kernel@...r.kernel.org, bsegall@...gle.com,
        boqun.feng@...il.com, swood@...hat.com, bristot@...hat.com,
        dietmar.eggemann@....com, mingo@...hat.com, jstultz@...gle.com,
        juri.lelli@...hat.com, mgorman@...e.de, rostedt@...dmis.org,
        vschneid@...hat.com, vincent.guittot@...aro.org,
        longman@...hat.com, will@...nel.org
Subject: Re: [PATCH 0/6] locking/rtmutex: Avoid PI state recursion through
 sched_submit_work()

On Tue, Aug 15, 2023 at 01:01:21PM +0200, Peter Zijlstra wrote:
> Hi!
> 
> This is basically the 'same' patches as send earlier by Sebastian here:
> 
>   https://lkml.kernel.org/r/20230427111937.2745231-1-bigeasy@linutronix.de
> 
> I spend a number of days trying to invert rtmutex, only to make a giant mess of
> things and finally conceded that this is the least horrible approach.
> 
> There's a bunch of naming differences and I added some asserts that should
> hopefully avoid things from going sideways without notice. I've also updated
> the changelogs to high-light the actual problem. The whole pi_blocked_on
> 'corruption' is a mere consequence of the more fundamental problem that the
> whole PI state recurses.
> 
> I've not tested this with the rest of the RT patches stuck on, so very limited
> actual testing happened.
> 
> If anybody could please confirm stuff still works as advertised, I'll go queue
> this mess and we can hopefully forget all about it.
> 

N/m - 0day found a problem. Futex-PI trips the rt_mutex_schedule()
assertion for not passing through rt_mutex_pre_schedule().

I'll go try and untangle that...