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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ