* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mi...@kernel.org> wrote:
> > diff --git a/mm/usercopy.c b/mm/usercopy.c
> > index 35685a236e34..2ce59b236d23 100644
> > --- a/mm/usercopy.c
> > +++ b/mm/usercopy.c
> > @@ -17,6 +17,11 @@
> > #include <linux/mm.h>
> > #include <linux/slab.h>
> > #include <linux/sched.h>
> > +<<<<<<< HEAD
> > +=======
> > +#include <linux/sched/task.h>
> > +#include <linux/sched/task_stack.h>
> > +>>>>>>> 9ecfbdbd2d46... fork.h fixes
> > #include <asm/sections.h>
> >
> > enum {
>
> This was clearly never actually tested. It was hidden in all the silly
> one-liner noise. See previous email about how nobody ever looks at
> that.
Ouch. Note that I did test the TILE cross-build on the resulting tree:
testing sparc: -git: pass ( 0), -tip: pass ( 0)
testing tile: -git: pass ( 2), -tip: pass ( 2)
^^^^^^^^^^^^^^^^^^^
testing um: -git: pass ( 0), -tip: pass ( 0)
... but this ugliness was hidden by the fact that a later patch removed the
merge
artifact:
[PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out of
<linux/sched.h>
diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
index 1e0509a4c8bd..f58fa06a2214 100644
--- a/arch/tile/mm/fault.c
+++ b/arch/tile/mm/fault.c
@@ -17,11 +17,8 @@
#include <linux/signal.h>
#include <linux/sched.h>
#include <linux/sched/debug.h>
-<<<<<<< HEAD
-=======
#include <linux/sched/task.h>
#include <linux/sched/task_stack.h>
->>>>>>> 9ecfbdbd2d46... fork.h fixes
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
... which doesn't excuse this in any way, of course. I've fixed it and I've
double
checked there are no other merge artifacts.
Not sure what happened there, my workflow usually warns about merge artifacts
:-/
These appear to have been the only such incidents:
triton:~/tip> git log -p 248fd141c4c1..WIP.sched/core | grep '===='
-=======
-=======
+=======
+=======
... but my confidence in this series just dropped rather significantly, will do
a
full restructuring & review of it.
Thanks,
Ingo
