linux-kernel - Re: [PATCH 20/89] sched/headers, signals: Separate out task_struct::signal and task_struct::sighand types and accessors into <linux/sched/signal.h>

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:   Mon, 6 Feb 2017 13:57:53 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Galbraith <efault@....de>,
        Oleg Nesterov <oleg@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 20/89] sched/headers, signals: Separate out
 task_struct::signal and task_struct::sighand types and accessors into <linux/sched/signal.h>

On Mon, Feb 6, 2017 at 1:35 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> BTW., most of the real work was in identifying and generating that "noise" - but
> to reviewers it's obviously the least interesting bits.
>
> Also note that beyond the header splitup the "noise" is actually what improves
> kernel code the most all around

Oh, absolutely agreed. The "noise" is obviously the most important
part and the most challenging to actually generate (although maybe
some automation tool could do a lot of this in a perfect world).

But the noise is also the one where verification is pretty much purely
about "does it still compile", so from a human angle, once the noise
has been generated, it's not actually all that interesting.

It's kind of like being NP complete: verification of the noise is
"trivial" and not all that interesting - once the solution has been
find.

> Will post them in 4 groups of 40 patches each or so - would that work for you?

I suspect that will be a lot easier.to look at (with at least one
series basically being "there's no point in a human even looking at
it, other than to verify that it's purely #include changes").

It would be good to make sure it also ends up bisecting nicely,
because *if* some problem happens, it would be nice if the bisect then
clearly points to either "oh, some mistake must have happened during
code movement" vs "ooh, some really subtle issue with a missed include
causing some odd fallback code".

Because we *do* end up having code in C files that does things like

   #ifndef ARCH_HAS_XYZ
   static inline void my_generic_xyz_implementation(...)
   ...
    #endif

so you can end up in the situation that if some specific header file
wasn't included correctly, the code will still work, but now it will
use the generic definition rather than the specific one it was
supposed to use.

So these re-organizations do have the potential to cause odd "silent"
breakage. Most breakage by far should presumably be of the type "it
doesn't compile and it's very obvious that the header file movement
missed something", but we *could* have that kind of subtle "it
compiles, and _almost_ even works, but has a cornercase that is
broken" that could be fingered by a bisect.

That's when a good split of patches would be really nice to have too,
where a patch does either code movement or does header file
organization movement, but not both.

So it's not _just_ about actually looking at the patches and trying to
make sense of them.

                     Linus