linux-kernel - Re: [PATCH] firmware: wake all waiters

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: <20170628134514.GA2644@linux-80c1.suse>
Date:   Wed, 28 Jun 2017 06:45:14 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        DanielWagnerwagi@...om.org, Boqun Feng <boqun.feng@...il.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Ming Lei <ming.lei@...hat.com>,
        "Li, Yi" <yi1.li@...ux.intel.com>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Petr Mladek <pmladek@...e.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <alan@...ux.intel.com>, Theodore Ts'o <tytso@....edu>,
        oss-drivers@...ronome.com
Subject: Re: [PATCH] firmware: wake all waiters

On Tue, 27 Jun 2017, Luis R. Rodriguez wrote:

>diff --git a/include/linux/swait.h b/include/linux/swait.h
>index 4a4e180d0a35..14fcf23cece4 100644
>--- a/include/linux/swait.h
>+++ b/include/linux/swait.h
>@@ -29,7 +29,10 @@
>  *
>  * As a side effect of this; the data structures are slimmer.
>  *
>- * One would recommend using this wait queue where possible.

So I think this was added due to the smaller footprint and fewer
cycles that swait has compared to the traditional (bulkier)
waitqueues. While probably not worth it, I guess we could offer
super-simple waitqueues (sswait? :-) which do not have the rt caveats
and uses a regular spinlock. The wakeup_all() call would not drop
the lock upon every wakeup as we are stripping the waitqueue not
for determinism, but for overhead. To mitigate this, we might
also want to use wake_q for reduced hold q->lock hold times.

But I don't think its worth yet another wait interface.
Alternatively, it crossed my mind we could also have wakeup_all()
use in the regular waitqueues, but I'd have to audit all the
current users to make sure we could actually do this.

Thanks,
Davidlohr