Re: [PATCH 52/89] sched/headers: Split <linux/sched/task.h> out of <linux/sched.h>

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> 
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mingo@xxxxxxxxxx> 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 '===='
>   -=======
>   -=======
>   +=======
>   +=======

Actually, this was already in the fixed tree, so there was another merge 
artifact...

Thanks,

	Ingo