linux-kernel - Re: [PATCH -v4 00/10] FUTEX_UNLOCK

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: <20161216233140.GC62123@f23x64.localdomain>
Date:   Fri, 16 Dec 2016 15:31:40 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     tglx@...utronix.de, mingo@...nel.org, juri.lelli@....com,
        rostedt@...dmis.org, xlpang@...hat.com, bigeasy@...utronix.de,
        linux-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
        jdesfossez@...icios.com, bristot@...hat.com
Subject: Re: [PATCH -v4 00/10] FUTEX_UNLOCK_PI wobbles

On Tue, Dec 13, 2016 at 09:36:38AM +0100, Peter Zijlstra wrote:
> 
> Hi all,
> 
> This is (I think) the 4th attempt at fixing this tiny pesky issue with
> FUTEX_UNLOCK_PI, where we would really like to drop (and unboost) the rt_mutex
> without holding hb->lock.
> 
> While going through the requeue PI code and thinking about how all that worked
> I realized we can avoid the entire problem I've been trying to solve. That is,
> the 'problem' is that futex state and rt_mutex state can end up disagreeing on
> who is waiting for the lock and we muddle around that with intricate state.
> 
> This series, well patch 8, avoids the entire problem by making sure this
> inconsistent state does not occur. Which then simplifies everything -- assuming
> I got it right of course :-)
> 
> The basic idea is to, like requeue PI, break the rt_mutex_lock() function into
> pieces, such that we can enqueue the waiter while holding hb->lock, wait for
> acquisition without hb->lock and can remove the waiter, on failure, while
> holding hb->lock again.

Oh boy, this is going to take some brain space/time. I'll comment as I work
through them and ask questions - to keep the dialog going.

> 
> That way, when we drop hb->lock to wait, futex and rt_mutex wait state is
> consistent.
> 
> 
> In any case, it passes our inadequate testing.

It passed my CI tools/testing/selftests/futex/functional/run.sh. Did you also
happen to run a fuzz tester?

-- 
Darren Hart
Intel Open Source Technology Center