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]
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

Powered by blists - more mailing lists