Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1575148 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 52/89] sched/headers: Split <linux/sched/task.h> out of <linux/sched.h> Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-06 22:20 +0100
    Re: [PATCH 52/89] sched/headers: Split <linux/sched/task.h> out of  <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-06 22:50 +0100
      Re: [PATCH 52/89] sched/headers: Split <linux/sched/task.h> out of  <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-06 22:50 +0100

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

On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mingo@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.

                  Linus

[toc] | [next] | [standalone]

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

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

> On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mingo@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

[toc] | [prev] | [next] | [standalone]

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

* Ingo Molnar <mingo@kernel.org> wrote:

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

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

Thanks,

	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web