linux-kernel - Re: Sum of weights idea for CFS PI

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: <YzweGw5l3HxQVcGN@linutronix.de>
Date:   Tue, 4 Oct 2022 13:50:51 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Qais Yousef <qais.yousef@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>, juri.lelli@...hat.com,
        vincent.guittot@...aro.org,
        Youssef Esmat <youssefesmat@...gle.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Thomas Gleixner <tglx@...utronix.de>, bristot@...hat.com,
        clark.williams@...il.com, "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Sum of weights idea for CFS PI

On 2022-09-30 13:34:49 [-0400], Joel Fernandes wrote:
> In this case, there is no lock involved yet you have a dependency. But I don't
> mean to sound depressing, and just because there are cases like this does not
> mean we should not solve the lock-based ones. When I looked at Android, I saw
> that it uses futex directly from Android Runtime code instead of using pthread.
> So perhaps this can be trivially converted to FUTEX_LOCK_PI and then what we do
> in the kernel will JustWork(Tm) ?

The easy part is just to replace the lock/unlock functions with
FUTEX_LOCK_PI/UNLOCK_PI syscalls. The slightly advanced part is where
you use an atomic operation to replace 0 with threads's ID in the lock
path to avoid going into the kernel for locking if the lock is not
contended. If it is, then you need to use the syscall.

…
> > Proxy execution seems to be the nice solution to all of these problems, but
> > it's a long way away. I'm interested to learn how this inheritance will be
> > implemented. And whether there are any userspace conversion issues. i.e: do
> > we need to convert all locks to rt-mutex locks?
> 
> I am not an expert on FUTEX_LOCK_PI and this could be a good time for tglx to
> weigh in, but I think converting all userspace locks to use FUTEX_LOCK_PI sounds
> reasonable to me.

Based on my understanding with proxy-execution, all in-kernel locks
should be covered.
Priority inheritance (PI) works only with FUTEX_LOCK_PI for userpace and
rtmutex for the in-kernel locks. Regular FUTEX_LOCK does only wait/wake
in userspace so there is no way for the kernel to "help". Ah and for PI
to work you need priorities that you can inherit. With two threads
running as SCHED_OTHER there will be just "normal" sleep+wake in the
kernel. If the blocking thread is SCHED_FIFO then it will inherit its
priority to the lock owner.

> Other thoughts?
> 
> thanks,
> 
>  - Joel

Sebastian