linux-kernel - Re: [patch V3 50/64] locking/rtmutex: Extend the rtmutex core to support ww

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: <8735rl5894.ffs@tglx>
Date:   Sat, 07 Aug 2021 22:07:19 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Davidlohr Bueso <dave@...olabs.net>,
        Mike Galbraith <efault@....de>
Subject: Re: [patch V3 50/64] locking/rtmutex: Extend the rtmutex core to
 support ww_mutex

On Fri, Aug 06 2021 at 15:48, Peter Zijlstra wrote:

> On Fri, Aug 06, 2021 at 01:00:51PM +0200, Peter Zijlstra wrote:
>> Also, I found a note that said I had to check what this code does for
>> !RT tasks, lemme go do that now.
>
> Do we want something like the below?

I think so.

> AFAICT the existing RB-tree actually does FIFO for equal prio right. Per
> rb_add_cached() we only go left for less, therefore equal goes right,
> giving a tail-add for equal prio.
>
> Furthermore, rt_mutex_adjust_prio_chain() is careful not to requeue when
> the priority doesn't change, preserving this FIFO order (as is mandated
> by SCHED_FIFO semantics IIRC).
>
> Therefore, all that seems to be missing is to squash all !RT tasks to
> the same prio to make sure they're all FIFO ordered.

The reason why the nice value is accounted for today is that it gave
more exposure to the PI code. But yes, we can squash all !RT tasks and
let them queue in FIFO order.

Let me add that to the series.

Thanks,

        tglx