linux-kernel - Re: [RFC PATCH] sched/wait: Introduce new, more compact wait

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: <CA+55aFw8Py8ASo6-BqBzPOe2jmoJokeFpHEp7cpV4T9geVwBrw@mail.gmail.com>
Date:   Wed, 8 Mar 2017 08:37:37 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH] sched/wait: Introduce new, more compact wait_event*() primitives

On Wed, Mar 8, 2017 at 12:37 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> The idea is to allow call sites to supply the 'condition' function as free-form C
> code, while pushing everything else into non-macro form: there's a 'struct
> wait_event_state' on stack, and a state machine. The waiting logic is converted
> from procedural form to a state machine, because we have to call out into the
> 'condition' code in different circumstances.

Ok, I think the concept is fine, but you don't actually fix the
problem with the locked version that needs to unlock (with irq
versions etc) around the schedule.

And using "bool" in a struct is disgusting and wrong, and hides the
fact that the compiler will just turn it into "char" (or even "int"
for platforms where "char'" is slow, like alpha).

So it would be better with a "state" variable that just has fields, I suspect.

.. and as mentioned, it doesn't actually fix the case that hit the
signal_pending() problem.

Honestly, I think my "pass in a waiter function" model was both less
subtle and indirect, and more generic.

And we can actually *fix* the problem with it for 4.11, instead of
adding the stupid header file includes.

                     Linus