linux-kernel - Re: [PATCH v2 00/12] Reviving the Proxy Execution Series v2

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCq90WkGkA1Q-u8tWirik7i52zGN1ks_4-A_A5MpU+Gkpg@mail.gmail.com>
Date:   Mon, 20 Mar 2023 19:51:03 -0700
From:   John Stultz <jstultz@...gle.com>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     Joel Fernandes <joelaf@...gle.com>,
        Qais Yousef <qyousef@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Valentin Schneider <vschneid@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>,
        Zimuzo Ezeozue <zezeozue@...gle.com>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>, kernel-team@...roid.com
Subject: Re: [PATCH v2 00/12] Reviving the Proxy Execution Series v2

On Mon, Mar 20, 2023 at 4:37 PM John Stultz <jstultz@...gle.com> wrote:
> Changes since Connor’s last submission:
> ---------------------------------------
> * I dropped the patch changing mutex::wait_lock to always save/restore irq
>   flags (as Joel raised a concern that the patch wasn’t actually
>   necessary).

Well, despite a bit of testing prior, it is of course immediately
after sending it I managed to trip lockdep to get a warning on this
(though it tripped on the blocked_lock not the wait_lock), so I'll be
re-adding that patch (or a variant) back in in the next series.

[    1.351993]        CPU0                    CPU1
[    1.351993]        ----                    ----
[    1.351993]   lock(&p->blocked_lock);
[    1.351993]                                local_irq_disable();
[    1.351993]                                lock(&rq->__lock);
[    1.351993]                                lock(&p->blocked_lock);
[    1.351993]   <Interrupt>
[    1.351993]     lock(&rq->__lock);

thanks
-john