linux-kernel - Re: [GIT PULL] sched.h split-up

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+55aFz4CKT-yCUfQT6bDC9OyMUw4SLAoatxiVAizD0JzKtqxA@mail.gmail.com>
Date:   Tue, 7 Mar 2017 15:33:14 -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: [GIT PULL] sched.h split-up

On Fri, Mar 3, 2017 at 12:13 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The fact that you can include <linux/wait.h>, and then cannot use the
> wait event functions because you're missing "signal_pending()" is
> complete garbage. This needs to be fixed.

Here's a (totally untested) patch that tries to do exactly that.

It moves the stuff inside the wait-loop into two helper functions -
one for "interrupts off" and one for "interrupts on" case - and does
the meat of the whole __wait_event_interruptible_locked() out of line.

NOTE! This is all the slow case, when we will schedule and mess around
with spinlocks. The fast case will have been taken care of by the
macros that then use the whole "__wait_event_interruptible_locked()"
machinery.

So moving it out of line not only makes the build simpler (no need for
<linux/sched/signal.h> for the "signal_pending()" thing), but seems to
be the right thing to do from a code size standpoint too.

But as mentioned - this is untested. It seems to build, and it looks
"ObviouslyCorrect(tm)", but I didn't actually try to boot it.

Comments?

                     Linus

View attachment "patch.diff" of type "text/plain" (4275 bytes)