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

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

Date:   Sat, 4 Mar 2017 08:30:17 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> Anyway, I fixed the semantic merge error by just including thar
> <linux/sched/signal.h> file, but this is just not acceptable.
> 
> Having to have files know that if they use the wait-event functins
> (well, _some_ of them), they not only need to include <linux/wait.h>,
> they need to completely illogically also include
> <linux/sched/signal.h> is just not maintainable.

Absolutely and agreed, will fix this ASAP!

wait.h generates too large functions anyway, so uninlining parts of it will be an 
improvement anyway.

> And who knows what similar semantic cases I _won't_ notice, because
> they occur in code I don't build even with my allmodconfig builds?

I did a fair amount of allyes/allno/allmod plus randconfig testing on x86, and 
caught and fixed a number of cases, so that angle should be covered to a fair 
degree.

On non-x86 I did allyes/allno/allmod testing as well, but not randconfig testing - 
plus some of the architectures have a large amount of defconfigs which I couldn't 
all test through.

So I'd expect build breakages to be concentrated into newly upstreamed code (such 
as this one) - which risk I tried to reduce by re-testing them on the almost-last 
day of the merge window.

Thanks,

	Ingo