Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the tip tree
@ 2010-07-29  3:04 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2010-07-29  3:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jason Wessel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

kernel/debug/kdb/kdb_main.c: In function 'kdb_summary':
kernel/debug/kdb/kdb_main.c:2457: error: 'xtime' undeclared (first use in this function)

Caused by commit 0fb86b06298b6cd3205cac2e68a499f269282dac ("imekeeping:
Make xtime and wall_to_monotonic static") from the tip tree interacting
with commit 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb
back end (1 of 2)") which was merged before v2.6.35-rc1.

I have used the tip tree from next-20100727 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-11-06  2:53 ` Stephen Rothwell
@ 2019-11-27 23:39   ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-11-27 23:39 UTC (permalink / raw)
  To: Dave Airlie, DRI
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Chris Wilson,
	Qian Cai, Linus

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Hi all,

On Wed, 6 Nov 2019 13:53:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I added the following merge fix patch for today:
> >   
> 
> This patch is now just:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 10 Oct 2019 13:08:43 +1100
> Subject: [PATCH] drm/i915: update for mutex_release API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/i915/i915_active.c    | 2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
> index aa37c07004b9..a47387174434 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
>  	mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
>  	if (!__i915_active_fence_set(&ref->excl, f))
>  		atomic_inc(&ref->count);
> -	mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
> +	mutex_release(&ref->mutex.dep_map, _THIS_IP_);
>  }
>  
>  bool i915_active_acquire_if_busy(struct i915_active *ref)
> -- 
> 2.23.0

This merge fix patch is now needed for the merge between the drm tree
and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-11-21  3:54 Stephen Rothwell
  2019-11-21  8:36 ` Peter Zijlstra
@ 2019-11-21 18:37 ` Alex Deucher
  1 sibling, 0 replies; 245+ messages in thread
From: Alex Deucher @ 2019-11-21 18:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI, Alex Deucher, Linux Next Mailing List,
	Linux Kernel Mailing List, Kevin Wang

On Wed, Nov 20, 2019 at 10:54 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/trace/define_trace.h:102,
>                  from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502,
>                  from drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c:29:
> include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:476:52: error: expected expression before ';' token
>   476 |         __string(ring, sched_job->base.sched->name);
>       |                                                    ^
> include/trace/trace_events.h:435:2: note: in definition of macro 'DECLARE_EVENT_CLASS'
>   435 |  tstruct        \
>       |  ^~~~~~~
> include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
>    77 |         PARAMS(tstruct),         \
>       |         ^~~~~~
> include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:472:1: note: in expansion of macro 'TRACE_EVENT'
>   472 | TRACE_EVENT(amdgpu_ib_pipe_sync,
>       | ^~~~~~~~~~~
> include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:475:6: note: in expansion of macro 'TP_STRUCT__entry'
>   475 |      TP_STRUCT__entry(
>       |      ^~~~~~~~~~~~~~~~
>
> Caused by commit
>
>   2c2fdb8bca29 ("drm/amdgpu: fix amdgpu trace event print string format error")
>
> from the drm tree interacting with commit
>
>   60fdad00827c ("ftrace: Rework event_create_dir()")
>
> from the tip tree.
>
> I have added the following merge fix patch:

Applied.  Thanks!

Alex

>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 21 Nov 2019 14:46:00 +1100
> Subject: [PATCH] merge fix for "ftrace: Rework event_create_dir()"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index f940526c5889..63e734a125fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> @@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync,
>             TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence),
>             TP_ARGS(sched_job, fence),
>             TP_STRUCT__entry(
> -                            __string(ring, sched_job->base.sched->name);
> +                            __string(ring, sched_job->base.sched->name)
>                              __field(uint64_t, id)
>                              __field(struct dma_fence *, fence)
>                              __field(uint64_t, ctx)
> --
> 2.23.0
>
> --
> Cheers,
> Stephen Rothwell
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-11-21  3:54 Stephen Rothwell
@ 2019-11-21  8:36 ` Peter Zijlstra
  2019-11-21 18:37 ` Alex Deucher
  1 sibling, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2019-11-21  8:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Dave Airlie, DRI,
	Linux Next Mailing List, Linux Kernel Mailing List, Kevin Wang,
	Alex Deucher

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Thu, Nov 21, 2019 at 02:54:03PM +1100, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index f940526c5889..63e734a125fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> @@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync,
>  	    TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence),
>  	    TP_ARGS(sched_job, fence),
>  	    TP_STRUCT__entry(
> -			     __string(ring, sched_job->base.sched->name);
> +			     __string(ring, sched_job->base.sched->name)
>  			     __field(uint64_t, id)
>  			     __field(struct dma_fence *, fence)
>  			     __field(uint64_t, ctx)

Correct, ';' there is invalid and now results in very verbose compile
errors :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-11-21  3:54 Stephen Rothwell
  2019-11-21  8:36 ` Peter Zijlstra
  2019-11-21 18:37 ` Alex Deucher
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-11-21  3:54 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kevin Wang,
	Alex Deucher

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from include/trace/define_trace.h:102,
                 from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502,
                 from drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c:29:
include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:476:52: error: expected expression before ';' token
  476 |         __string(ring, sched_job->base.sched->name);
      |                                                    ^
include/trace/trace_events.h:435:2: note: in definition of macro 'DECLARE_EVENT_CLASS'
  435 |  tstruct        \
      |  ^~~~~~~
include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
   77 |         PARAMS(tstruct),         \
      |         ^~~~~~
include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:472:1: note: in expansion of macro 'TRACE_EVENT'
  472 | TRACE_EVENT(amdgpu_ib_pipe_sync,
      | ^~~~~~~~~~~
include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:475:6: note: in expansion of macro 'TP_STRUCT__entry'
  475 |      TP_STRUCT__entry(
      |      ^~~~~~~~~~~~~~~~

Caused by commit

  2c2fdb8bca29 ("drm/amdgpu: fix amdgpu trace event print string format error")

from the drm tree interacting with commit

  60fdad00827c ("ftrace: Rework event_create_dir()")

from the tip tree.

I have added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Nov 2019 14:46:00 +1100
Subject: [PATCH] merge fix for "ftrace: Rework event_create_dir()"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index f940526c5889..63e734a125fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync,
 	    TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence),
 	    TP_ARGS(sched_job, fence),
 	    TP_STRUCT__entry(
-			     __string(ring, sched_job->base.sched->name);
+			     __string(ring, sched_job->base.sched->name)
 			     __field(uint64_t, id)
 			     __field(struct dma_fence *, fence)
 			     __field(uint64_t, ctx)
-- 
2.23.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-11-18  3:11 Stephen Rothwell
  2019-11-18  9:49 ` Jiri Slaby
@ 2019-11-18 12:49 ` Borislav Petkov
  1 sibling, 0 replies; 245+ messages in thread
From: Borislav Petkov @ 2019-11-18 12:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Herbert Xu, Linux Crypto List, Linux Next Mailing List,
	Linux Kernel Mailing List, Jason A. Donenfeld, Samuel Neves,
	Ard Biesheuvel, Jiri Slaby, Linus Torvalds

On Mon, Nov 18, 2019 at 02:11:10PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/crypto/blake2s-core.S: Assembler messages:
> arch/x86/crypto/blake2s-core.S:50: Error: invalid character '(' in mnemonic
> arch/x86/crypto/blake2s-core.S:176: Error: invalid character '(' in mnemonic
> arch/x86/crypto/blake2s-core.S:180: Error: invalid character '(' in mnemonic
> arch/x86/crypto/blake2s-core.S:257: Error: invalid character '(' in mnemonic
> 
> Caused by commit
> 
>   ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
> 
> from the crypto tree interacting with commit
> 
>   6dcc5627f6ae ("x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*")
> 
> from the tip tree.
> 
> I have applied the following merge fix patch.

Thanks.

I need to remember to point Linus to it when I send the pull request
next week so that he's aware and can apply your patch when merging the
crypto tree.

Lemme CC him now too, as an FYI.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Nov 2019 14:00:40 +1100
> Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*"

<--- add a commit message blurb here pls.

> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/crypto/blake2s-core.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S
> index 8591938eee26..24910b766bdd 100644
> --- a/arch/x86/crypto/blake2s-core.S
> +++ b/arch/x86/crypto/blake2s-core.S
> @@ -47,7 +47,7 @@ SIGMA2:
>  
>  .text
>  #ifdef CONFIG_AS_SSSE3
> -ENTRY(blake2s_compress_ssse3)
> +SYM_FUNC_START(blake2s_compress_ssse3)
>  	testq		%rdx,%rdx
>  	je		.Lendofloop
>  	movdqu		(%rdi),%xmm0
> @@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3)
>  	movdqu		%xmm14,0x20(%rdi)
>  .Lendofloop:
>  	ret
> -ENDPROC(blake2s_compress_ssse3)
> +SYM_FUNC_END(blake2s_compress_ssse3)
>  #endif /* CONFIG_AS_SSSE3 */
>  
>  #ifdef CONFIG_AS_AVX512
> -ENTRY(blake2s_compress_avx512)
> +SYM_FUNC_START(blake2s_compress_avx512)
>  	vmovdqu		(%rdi),%xmm0
>  	vmovdqu		0x10(%rdi),%xmm1
>  	vmovdqu		0x20(%rdi),%xmm4
> @@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512)
>  	vmovdqu		%xmm4,0x20(%rdi)
>  	vzeroupper
>  	retq
> -ENDPROC(blake2s_compress_avx512)
> +SYM_FUNC_END(blake2s_compress_avx512)
>  #endif /* CONFIG_AS_AVX512 */
> -- 
> 2.23.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-11-18  3:11 Stephen Rothwell
@ 2019-11-18  9:49 ` Jiri Slaby
  2019-11-18 12:49 ` Borislav Petkov
  1 sibling, 0 replies; 245+ messages in thread
From: Jiri Slaby @ 2019-11-18  9:49 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Herbert Xu, Linux Crypto List
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Jason A. Donenfeld, Samuel Neves, Ard Biesheuvel,
	Borislav Petkov

[-- Attachment #1.1: Type: text/plain, Size: 1508 bytes --]

On 18. 11. 19, 4:11, Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Nov 2019 14:00:40 +1100
> Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/crypto/blake2s-core.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S
> index 8591938eee26..24910b766bdd 100644
> --- a/arch/x86/crypto/blake2s-core.S
> +++ b/arch/x86/crypto/blake2s-core.S
> @@ -47,7 +47,7 @@ SIGMA2:
>  
>  .text
>  #ifdef CONFIG_AS_SSSE3
> -ENTRY(blake2s_compress_ssse3)
> +SYM_FUNC_START(blake2s_compress_ssse3)
>  	testq		%rdx,%rdx
>  	je		.Lendofloop
>  	movdqu		(%rdi),%xmm0
> @@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3)
>  	movdqu		%xmm14,0x20(%rdi)
>  .Lendofloop:
>  	ret
> -ENDPROC(blake2s_compress_ssse3)
> +SYM_FUNC_END(blake2s_compress_ssse3)
>  #endif /* CONFIG_AS_SSSE3 */
>  
>  #ifdef CONFIG_AS_AVX512
> -ENTRY(blake2s_compress_avx512)
> +SYM_FUNC_START(blake2s_compress_avx512)
>  	vmovdqu		(%rdi),%xmm0
>  	vmovdqu		0x10(%rdi),%xmm1
>  	vmovdqu		0x20(%rdi),%xmm4
> @@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512)
>  	vmovdqu		%xmm4,0x20(%rdi)
>  	vzeroupper
>  	retq
> -ENDPROC(blake2s_compress_avx512)
> +SYM_FUNC_END(blake2s_compress_avx512)
>  #endif /* CONFIG_AS_AVX512 */

Hi, FWIW LGTM.

thanks,
-- 
js
suse labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-11-18  3:11 Stephen Rothwell
  2019-11-18  9:49 ` Jiri Slaby
  2019-11-18 12:49 ` Borislav Petkov
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-11-18  3:11 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Herbert Xu, Linux Crypto List
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Jason A. Donenfeld, Samuel Neves, Ard Biesheuvel,
	Borislav Petkov, Jiri Slaby

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/crypto/blake2s-core.S: Assembler messages:
arch/x86/crypto/blake2s-core.S:50: Error: invalid character '(' in mnemonic
arch/x86/crypto/blake2s-core.S:176: Error: invalid character '(' in mnemonic
arch/x86/crypto/blake2s-core.S:180: Error: invalid character '(' in mnemonic
arch/x86/crypto/blake2s-core.S:257: Error: invalid character '(' in mnemonic

Caused by commit

  ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")

from the crypto tree interacting with commit

  6dcc5627f6ae ("x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*")

from the tip tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Nov 2019 14:00:40 +1100
Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/crypto/blake2s-core.S | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S
index 8591938eee26..24910b766bdd 100644
--- a/arch/x86/crypto/blake2s-core.S
+++ b/arch/x86/crypto/blake2s-core.S
@@ -47,7 +47,7 @@ SIGMA2:
 
 .text
 #ifdef CONFIG_AS_SSSE3
-ENTRY(blake2s_compress_ssse3)
+SYM_FUNC_START(blake2s_compress_ssse3)
 	testq		%rdx,%rdx
 	je		.Lendofloop
 	movdqu		(%rdi),%xmm0
@@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3)
 	movdqu		%xmm14,0x20(%rdi)
 .Lendofloop:
 	ret
-ENDPROC(blake2s_compress_ssse3)
+SYM_FUNC_END(blake2s_compress_ssse3)
 #endif /* CONFIG_AS_SSSE3 */
 
 #ifdef CONFIG_AS_AVX512
-ENTRY(blake2s_compress_avx512)
+SYM_FUNC_START(blake2s_compress_avx512)
 	vmovdqu		(%rdi),%xmm0
 	vmovdqu		0x10(%rdi),%xmm1
 	vmovdqu		0x20(%rdi),%xmm4
@@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512)
 	vmovdqu		%xmm4,0x20(%rdi)
 	vzeroupper
 	retq
-ENDPROC(blake2s_compress_avx512)
+SYM_FUNC_END(blake2s_compress_avx512)
 #endif /* CONFIG_AS_AVX512 */
-- 
2.23.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-10  2:14 Stephen Rothwell
  2019-10-10  8:02 ` Ingo Molnar
@ 2019-11-06  2:53 ` Stephen Rothwell
  2019-11-27 23:39   ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-11-06  2:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Chris Wilson,
	Qian Cai

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

Hi all,

On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I added the following merge fix patch for today:
> 

This patch is now just:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 10 Oct 2019 13:08:43 +1100
Subject: [PATCH] drm/i915: update for mutex_release API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/i915/i915_active.c    | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index aa37c07004b9..a47387174434 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
 	mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
 	if (!__i915_active_fence_set(&ref->excl, f))
 		atomic_inc(&ref->count);
-	mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
+	mutex_release(&ref->mutex.dep_map, _THIS_IP_);
 }
 
 bool i915_active_acquire_if_busy(struct i915_active *ref)
-- 
2.23.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-21  5:51 ` Ingo Molnar
@ 2019-10-21  6:37   ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-10-21  6:37 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

Hi Ingo,

On Mon, 21 Oct 2019 07:51:41 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> Hm, that was a weird merge mishap - sorry about that, should go away in 
> the next -next iteration.

Thanks.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-21  2:13 Stephen Rothwell
@ 2019-10-21  5:51 ` Ingo Molnar
  2019-10-21  6:37   ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2019-10-21  5:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (native perf)
> failed like this:
> 
> make: execvp: ./check-headers.sh: Permission denied
> 
> Caused by commit
> 
>   05f2f277053d ("Merge branch 'x86/core'")
> 
> which somehow removed execute permissions from tools/perf/check-headers.sh
> 
> I added a commit to reenable execute permissions.

Hm, that was a weird merge mishap - sorry about that, should go away in 
the next -next iteration.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-10-21  2:13 Stephen Rothwell
  2019-10-21  5:51 ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-10-21  2:13 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (native perf)
failed like this:

make: execvp: ./check-headers.sh: Permission denied

Caused by commit

  05f2f277053d ("Merge branch 'x86/core'")

which somehow removed execute permissions from tools/perf/check-headers.sh

I added a commit to reenable execute permissions.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-10 11:23   ` Stephen Rothwell
@ 2019-10-10 13:44     ` Daniel Vetter
  0 siblings, 0 replies; 245+ messages in thread
From: Daniel Vetter @ 2019-10-10 13:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Peter Zijlstra, Linux Kernel Mailing List, DRI,
	Dave Airlie, Linux Next Mailing List, Qian Cai, H. Peter Anvin,
	Thomas Gleixner, Ingo Molnar

On Thu, Oct 10, 2019 at 10:23:21PM +1100, Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > I suspect -next will have to carry this semantic merge conflict 
> > resolution until the DRM tree is merged upstream.
> 
> Yep, its not a real problem, I get a few like this every cycle.

Yeah totally within expectations when I acked that cleanup patch. We'll
probably have a few more lockdep annotation patches/changes that will
conflict in drm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-10  8:02 ` Ingo Molnar
@ 2019-10-10 11:23   ` Stephen Rothwell
  2019-10-10 13:44     ` Daniel Vetter
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-10-10 11:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI, Linux Next Mailing List,
	Linux Kernel Mailing List, Chris Wilson, Qian Cai

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

Hi Ingo,

On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> I suspect -next will have to carry this semantic merge conflict 
> resolution until the DRM tree is merged upstream.

Yep, its not a real problem, I get a few like this every cycle.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-10-10  2:14 Stephen Rothwell
@ 2019-10-10  8:02 ` Ingo Molnar
  2019-10-10 11:23   ` Stephen Rothwell
  2019-11-06  2:53 ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2019-10-10  8:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI, Linux Next Mailing List,
	Linux Kernel Mailing List, Chris Wilson, Qian Cai


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
> drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release" passed 3 arguments, but takes just 2
>   183 |    mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
>       |                                                      ^
> In file included from include/linux/spinlock_types.h:18,
>                  from include/linux/spinlock.h:83,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from include/linux/slab.h:15,
>                  from include/linux/io-mapping.h:10,
>                  from drivers/gpu/drm/i915/i915_drv.h:36,
>                  from drivers/gpu/drm/i915/gt/intel_gt_pm.c:7:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
>   605 | #define mutex_release(l, i)   lock_release(l, i)
>       | 
> drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__context_pin_release':
> drivers/gpu/drm/i915/gt/intel_lrc.c:245:51: error: macro "mutex_release" passed 3 arguments, but takes just 2
>   245 |  mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_);
>       |                                                   ^
> In file included from include/linux/hardirq.h:6,
>                  from include/linux/interrupt.h:11,
>                  from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
>   605 | #define mutex_release(l, i)   lock_release(l, i)
>       | 
> 
> Caused by commit
> 
>   5facae4f3549 ("locking/lockdep: Remove unused @nested argument from lock_release()")
> 
> interacting with commits
> 
>   dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()")
>   fcde8c7eea60 ("drm/i915/selftests: Exercise potential false lite-restore")
>   b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
> 
> from the drm tree.
> 
> I added the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 10 Oct 2019 13:08:43 +1100
> Subject: [PATCH] drm/i915: update for mutex_release API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
>  drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
>  drivers/gpu/drm/i915/i915_active.c    | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

I suspect -next will have to carry this semantic merge conflict 
resolution until the DRM tree is merged upstream.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-10-10  2:14 Stephen Rothwell
  2019-10-10  8:02 ` Ingo Molnar
  2019-11-06  2:53 ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-10-10  2:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Chris Wilson,
	Qian Cai

[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release" passed 3 arguments, but takes just 2
  183 |    mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
      |                                                      ^
In file included from include/linux/spinlock_types.h:18,
                 from include/linux/spinlock.h:83,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:6,
                 from include/linux/slab.h:15,
                 from include/linux/io-mapping.h:10,
                 from drivers/gpu/drm/i915/i915_drv.h:36,
                 from drivers/gpu/drm/i915/gt/intel_gt_pm.c:7:
include/linux/lockdep.h:605: note: macro "mutex_release" defined here
  605 | #define mutex_release(l, i)   lock_release(l, i)
      | 
drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__context_pin_release':
drivers/gpu/drm/i915/gt/intel_lrc.c:245:51: error: macro "mutex_release" passed 3 arguments, but takes just 2
  245 |  mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_);
      |                                                   ^
In file included from include/linux/hardirq.h:6,
                 from include/linux/interrupt.h:11,
                 from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
include/linux/lockdep.h:605: note: macro "mutex_release" defined here
  605 | #define mutex_release(l, i)   lock_release(l, i)
      | 

Caused by commit

  5facae4f3549 ("locking/lockdep: Remove unused @nested argument from lock_release()")

interacting with commits

  dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()")
  fcde8c7eea60 ("drm/i915/selftests: Exercise potential false lite-restore")
  b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")

from the drm tree.

I added the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 10 Oct 2019 13:08:43 +1100
Subject: [PATCH] drm/i915: update for mutex_release API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
 drivers/gpu/drm/i915/i915_active.c    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index b52e2ba3d092..d195e05a701f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -180,7 +180,7 @@ int intel_gt_resume(struct intel_gt *gt)
 			GEM_BUG_ON(!intel_context_is_pinned(ce));
 			mutex_acquire(&ce->pin_mutex.dep_map, 0, 0, _THIS_IP_);
 			ce->ops->reset(ce);
-			mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
+			mutex_release(&ce->pin_mutex.dep_map, _THIS_IP_);
 		}
 
 		engine->serial++; /* kernel context lost */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a2155d6bcdd2..aa61b0101bf8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -242,7 +242,7 @@ static void __context_pin_acquire(struct intel_context *ce)
 
 static void __context_pin_release(struct intel_context *ce)
 {
-	mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_);
+	mutex_release(&ce->pin_mutex.dep_map, _RET_IP_);
 }
 
 static void mark_eio(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index aa37c07004b9..a47387174434 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
 	mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
 	if (!__i915_active_fence_set(&ref->excl, f))
 		atomic_inc(&ref->count);
-	mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
+	mutex_release(&ref->mutex.dep_map, _THIS_IP_);
 }
 
 bool i915_active_acquire_if_busy(struct i915_active *ref)
-- 
2.23.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-08-29 12:24   ` Thomas Gleixner
@ 2019-08-29 13:04     ` Peter Zijlstra
  0 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2019-08-29 13:04 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Mark Brown,
	Liam Girdwood, Linux Next Mailing List,
	Linux Kernel Mailing List, Mac Chiang

On Thu, Aug 29, 2019 at 02:24:24PM +0200, Thomas Gleixner wrote:
> On Thu, 29 Aug 2019, Peter Zijlstra wrote:
> > On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 29 Aug 2019 16:08:49 +1000
> > > Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  sound/soc/intel/common/soc-intel-quirks.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> > > index e6357d306cb8..863a477d3405 100644
> > > --- a/sound/soc/intel/common/soc-intel-quirks.h
> > > +++ b/sound/soc/intel/common/soc-intel-quirks.h
> > > @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
> > >  SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
> > >  SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
> > >  SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> > > -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> > > +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
> > 
> > ARGHH... rebase again?
> 
> No. This is a conflict with the sound tree which added the MOBILE
> thingy. So what you could do for now is

Yes, SFR clarified that. This is a case of me doing email before waking
up.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-08-29  7:46 ` Peter Zijlstra
@ 2019-08-29 12:24   ` Thomas Gleixner
  2019-08-29 13:04     ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Thomas Gleixner @ 2019-08-29 12:24 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Mark Brown,
	Liam Girdwood, Linux Next Mailing List,
	Linux Kernel Mailing List, Mac Chiang

On Thu, 29 Aug 2019, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 29 Aug 2019 16:08:49 +1000
> > Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  sound/soc/intel/common/soc-intel-quirks.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> > index e6357d306cb8..863a477d3405 100644
> > --- a/sound/soc/intel/common/soc-intel-quirks.h
> > +++ b/sound/soc/intel/common/soc-intel-quirks.h
> > @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
> >  SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
> >  SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
> >  SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> > -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> > +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
> 
> ARGHH... rebase again?

No. This is a conflict with the sound tree which added the MOBILE
thingy. So what you could do for now is

#define INTEL_FAM6_KABYLAKE_MOBILE INTEL_FAM6_KABYLAKE_L

and remove that after both trees have hit mainline, i.e. around rc1.

Thanks,

	tglx


^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-08-29  6:20 Stephen Rothwell
@ 2019-08-29  7:46 ` Peter Zijlstra
  2019-08-29 12:24   ` Thomas Gleixner
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2019-08-29  7:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Mark Brown,
	Liam Girdwood, Linux Next Mailing List,
	Linux Kernel Mailing List, Mac Chiang

On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Aug 2019 16:08:49 +1000
> Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  sound/soc/intel/common/soc-intel-quirks.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> index e6357d306cb8..863a477d3405 100644
> --- a/sound/soc/intel/common/soc-intel-quirks.h
> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
>  SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
>  SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
>  SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);

ARGHH... rebase again?

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-08-29  6:20 Stephen Rothwell
  2019-08-29  7:46 ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-08-29  6:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Mark Brown, Liam Girdwood
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mac Chiang

[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from sound/soc/intel/boards/sof_rt5682.c:23:
sound/soc/intel/boards/../common/soc-intel-quirks.h: In function 'soc_intel_is_cml':
sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'?
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU'
 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
                                            ^~~~~
sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU'
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
 ^~~~~~~~~~~~~~~~
sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU'
 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
                                            ^~~~~
sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU'
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
 ^~~~~~~~~~~~~~~~
In file included from sound/soc/intel/atom/sst/sst_acpi.c:35:
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h: In function 'soc_intel_is_cml':
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'?
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU'
 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
                                            ^~~~~
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU'
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
 ^~~~~~~~~~~~~~~~
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU'
 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
                                            ^~~~~
sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU'
 SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
 ^~~~~~~~~~~~~~~~

Caused by commit

  af239c44e3f9 ("x86/intel: Aggregate big core mobile naming")

interacting with commit

  c643c189f0fe ("ASoC: Intel: boards: Add Cometlake machine driver support")

from the sound-asoc tree.

I have added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Aug 2019 16:08:49 +1000
Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/soc/intel/common/soc-intel-quirks.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
index e6357d306cb8..863a477d3405 100644
--- a/sound/soc/intel/common/soc-intel-quirks.h
+++ b/sound/soc/intel/common/soc-intel-quirks.h
@@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
 SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
 SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
 SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
-SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
+SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
 
 static inline bool soc_intel_is_byt_cr(struct platform_device *pdev)
 {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-08-08  4:48 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-08-08  4:48 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mukesh Ojha

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/locking/mutex-debug.c: In function 'debug_mutex_lock_common':
kernel/locking/mutex-debug.c:32:42: error: dereferencing pointer to incomplete type 'struct mutex_waiter'
  memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
                                          ^~~~~~~

Caused by commit

  5f35d5a66b3e ("locking/mutex: Make __mutex_owner static to mutex.c")

I have reverted that commit for today.

BTW, there is another reference to mutex_waiter in sched.h!
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-08-01  3:38 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-08-01  3:38 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Sebastian Andrzej Siewior, Anna-Maria Gleixner

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/android/vsoc.c: In function 'handle_vsoc_cond_wait':
drivers/staging/android/vsoc.c:440:33: error: passing argument 1 of 'hrtimer_init_sleeper_on_stack' from incompatible pointer type [-Werror=incompatible-pointer-types]
   hrtimer_init_sleeper_on_stack(&to, CLOCK_MONOTONIC,
                                 ^~~
In file included from include/linux/pm.h:16,
                 from include/linux/device.h:23,
                 from include/linux/dma-mapping.h:7,
                 from drivers/staging/android/vsoc.c:19:
include/linux/hrtimer.h:381:67: note: expected 'struct hrtimer_sleeper *' but argument is of type 'struct hrtimer_sleeper **'
 extern void hrtimer_init_sleeper_on_stack(struct hrtimer_sleeper *sl,
                                           ~~~~~~~~~~~~~~~~~~~~~~~~^~

Caused by commit

  82e18bace3dd ("hrtimer: Consolidate hrtimer_init() + hrtimer_init_sleeper() calls")

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 1 Aug 2019 13:33:44 +1000
Subject: [PATCH] hrtimer: fix typo in hrtimer_init_sleeper_on_stack() conversion

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/android/vsoc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 4f7e6c1dce42..1240bb0317d9 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -437,7 +437,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct vsoc_cond_wait *arg)
 			return -EINVAL;
 		wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec);
 
-		hrtimer_init_sleeper_on_stack(&to, CLOCK_MONOTONIC,
+		hrtimer_init_sleeper_on_stack(to, CLOCK_MONOTONIC,
 					      HRTIMER_MODE_ABS);
 		hrtimer_set_expires_range_ns(&to->timer, wake_time,
 					     current->timer_slack_ns);
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-10 18:21   ` Ilya Dryomov
@ 2019-07-10 21:38     ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-10 21:38 UTC (permalink / raw)
  To: Ilya Dryomov
  Cc: Sage Weil, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Nikolay Borisov

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

Hi Ilya,

On Wed, 10 Jul 2019 20:21:33 +0200 Ilya Dryomov <idryomov@gmail.com> wrote:
>
> Yes, that is what I figured would happen.  I assume you would keep
> carrying this fixup until the ceph tree is merged.

Of course.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-10  0:01 ` Stephen Rothwell
@ 2019-07-10 18:21   ` Ilya Dryomov
  2019-07-10 21:38     ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Ilya Dryomov @ 2019-07-10 18:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Sage Weil, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Nikolay Borisov

On Wed, Jul 10, 2019 at 2:01 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/block/rbd.c: In function 'wake_lock_waiters':
> > drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration]
> >   lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> >   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   lockdep_assert_held_write
> >
> > Caused by commit
> >
> >   9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> >
> > interacting with commits
> >
> >   637cd060537d ("rbd: new exclusive lock wait/wake code")
> >   a2b1da09793d ("rbd: lock should be quiesced on reacquire")
> >
> > from the ceph tree.
> >
> > I have added the following merge fix patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 9 Jul 2019 16:46:12 +1000
> > Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  drivers/block/rbd.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> > index 723c3ef4bd59..02216fbdb854 100644
> > --- a/drivers/block/rbd.c
> > +++ b/drivers/block/rbd.c
> > @@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result)
> >       struct rbd_img_request *img_req;
> >
> >       dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result);
> > -     lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> > +     lockdep_assert_held_write(&rbd_dev->lock_rwsem);
> >
> >       cancel_delayed_work(&rbd_dev->lock_dwork);
> >       if (!completion_done(&rbd_dev->acquire_wait)) {
> > @@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev)
> >       bool need_wait;
> >
> >       dout("%s rbd_dev %p\n", __func__, rbd_dev);
> > -     lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> > +     lockdep_assert_held_write(&rbd_dev->lock_rwsem);
> >
> >       if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED)
> >               return false;
>
> This fix now needs to be applied to the merge of the ceph tree.

Hi Stephen,

Yes, that is what I figured would happen.  I assume you would keep
carrying this fixup until the ceph tree is merged.

Thanks,

                Ilya

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-09  6:54 Stephen Rothwell
@ 2019-07-10  0:01 ` Stephen Rothwell
  2019-07-10 18:21   ` Ilya Dryomov
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-10  0:01 UTC (permalink / raw)
  To: Sage Weil
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov, Ilya Dryomov

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

Hi all,

On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/block/rbd.c: In function 'wake_lock_waiters':
> drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration]
>   lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   lockdep_assert_held_write
> 
> Caused by commit
> 
>   9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> 
> interacting with commits
> 
>   637cd060537d ("rbd: new exclusive lock wait/wake code")
>   a2b1da09793d ("rbd: lock should be quiesced on reacquire")
> 
> from the ceph tree.
> 
> I have added the following merge fix patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 9 Jul 2019 16:46:12 +1000
> Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/block/rbd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index 723c3ef4bd59..02216fbdb854 100644
> --- a/drivers/block/rbd.c
> +++ b/drivers/block/rbd.c
> @@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result)
>  	struct rbd_img_request *img_req;
>  
>  	dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result);
> -	lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> +	lockdep_assert_held_write(&rbd_dev->lock_rwsem);
>  
>  	cancel_delayed_work(&rbd_dev->lock_dwork);
>  	if (!completion_done(&rbd_dev->acquire_wait)) {
> @@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev)
>  	bool need_wait;
>  
>  	dout("%s rbd_dev %p\n", __func__, rbd_dev);
> -	lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> +	lockdep_assert_held_write(&rbd_dev->lock_rwsem);
>  
>  	if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED)
>  		return false;

This fix now needs to be applied to the merge of the ceph tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-07-09  6:54 Stephen Rothwell
  2019-07-10  0:01 ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-09  6:54 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Sage Weil
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov, Ilya Dryomov

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/block/rbd.c: In function 'wake_lock_waiters':
drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration]
  lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  lockdep_assert_held_write

Caused by commit

  9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")

interacting with commits

  637cd060537d ("rbd: new exclusive lock wait/wake code")
  a2b1da09793d ("rbd: lock should be quiesced on reacquire")

from the ceph tree.

I have added the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jul 2019 16:46:12 +1000
Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/rbd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 723c3ef4bd59..02216fbdb854 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result)
 	struct rbd_img_request *img_req;
 
 	dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result);
-	lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
+	lockdep_assert_held_write(&rbd_dev->lock_rwsem);
 
 	cancel_delayed_work(&rbd_dev->lock_dwork);
 	if (!completion_done(&rbd_dev->acquire_wait)) {
@@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev)
 	bool need_wait;
 
 	dout("%s rbd_dev %p\n", __func__, rbd_dev);
-	lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
+	lockdep_assert_held_write(&rbd_dev->lock_rwsem);
 
 	if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED)
 		return false;
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:04 Stephen Rothwell
  2019-06-25  6:23 ` Kalle Valo
  2019-07-09  0:09 ` Stephen Rothwell
@ 2019-07-09  3:46 ` Stephen Rothwell
  2 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-09  3:46 UTC (permalink / raw)
  To: Kalle Valo, Wireless
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld, David Miller,
	Networking

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

Hi all,

On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration]
>    rx_status->boottime_ns = ktime_get_boot_ns();
>                             ^~~~~~~~~~~~~~~~~
>                             ktime_get_raw_ns
> 
> Caused by commit
> 
>   c11c75ec784e ("p54: Support boottime in scan results")
> 
> from the wireless-drivers-next tree interacting with commit
> 
>   9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
> 
> from the tip tree.
> 
> I have added the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/net/wireless/intersil/p54/txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
>  
>  	fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
>  	if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> -		rx_status->boottime_ns = ktime_get_boot_ns();
> +		rx_status->boottime_ns = ktime_get_boottime_ns();
>  
>  	if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
>  		p54_pspoll_workaround(priv, skb);

This patch is now needed in the merge between the net-next tree and
Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:04 Stephen Rothwell
  2019-06-25  6:23 ` Kalle Valo
@ 2019-07-09  0:09 ` Stephen Rothwell
  2019-07-09  3:46 ` Stephen Rothwell
  2 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-09  0:09 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Kalle Valo, Wireless
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

Hi all,

On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration]
>    rx_status->boottime_ns = ktime_get_boot_ns();
>                             ^~~~~~~~~~~~~~~~~
>                             ktime_get_raw_ns
> 
> Caused by commit
> 
>   c11c75ec784e ("p54: Support boottime in scan results")
> 
> from the wireless-drivers-next tree interacting with commit
> 
>   9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
> 
> from the tip tree.
> 
> I have added the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/net/wireless/intersil/p54/txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
>  
>  	fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
>  	if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> -		rx_status->boottime_ns = ktime_get_boot_ns();
> +		rx_status->boottime_ns = ktime_get_boottime_ns();
>  
>  	if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
>  		p54_pspoll_workaround(priv, skb);
> -- 
> 2.20.1

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-02 10:28 ` David Sterba
  2019-07-02 12:57   ` Stephen Rothwell
@ 2019-07-08  6:50   ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-08  6:50 UTC (permalink / raw)
  To: David Sterba
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Hi David,

On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba <dsterba@suse.cz> wrote:
>
> On Tue, Jul 02, 2019 at 03:33:02PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > fs/btrfs/ctree.c: In function '__tree_mod_log_insert':
> > fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
> >   lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock);
> >   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   lockdep_assert_held_once
> > 
> > Caused by commit
> > 
> >   9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> > 
> > interacting with commits
> > 
> >   84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert")
> >   283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping")  
> 
> I can move the patches out of the for-5.3 branch and send them
> separately after the rename gets merged, they're merely adding the
> assertion and otherwise do not affect the rest of the code.
> 
> Fixing that in another way would probably need more synchronization
> between the branches but I don't think it's necessary in this case. The
> next for-next snapshot branch will fix the compilation issue.

I see that you removed those commits.  The conflict is no more.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-02 10:28 ` David Sterba
@ 2019-07-02 12:57   ` Stephen Rothwell
  2019-07-08  6:50   ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-02 12:57 UTC (permalink / raw)
  To: David Sterba
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Hi David,

On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba <dsterba@suse.cz> wrote:
>
> I can move the patches out of the for-5.3 branch and send them
> separately after the rename gets merged, they're merely adding the
> assertion and otherwise do not affect the rest of the code.
> 
> Fixing that in another way would probably need more synchronization
> between the branches but I don't think it's necessary in this case. The
> next for-next snapshot branch will fix the compilation issue.

Its a simple enough conflict for Linus to fix up as long as someone
tells him to expect it ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-07-02  5:33 Stephen Rothwell
@ 2019-07-02 10:28 ` David Sterba
  2019-07-02 12:57   ` Stephen Rothwell
  2019-07-08  6:50   ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: David Sterba @ 2019-07-02 10:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov

On Tue, Jul 02, 2019 at 03:33:02PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/btrfs/ctree.c: In function '__tree_mod_log_insert':
> fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
>   lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock);
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   lockdep_assert_held_once
> 
> Caused by commit
> 
>   9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> 
> interacting with commits
> 
>   84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert")
>   283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping")

I can move the patches out of the for-5.3 branch and send them
separately after the rename gets merged, they're merely adding the
assertion and otherwise do not affect the rest of the code.

Fixing that in another way would probably need more synchronization
between the branches but I don't think it's necessary in this case. The
next for-next snapshot branch will fix the compilation issue.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-07-02  5:33 Stephen Rothwell
  2019-07-02 10:28 ` David Sterba
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2019-07-02  5:33 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Sterba
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Nikolay Borisov

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/btrfs/ctree.c: In function '__tree_mod_log_insert':
fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
  lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  lockdep_assert_held_once

Caused by commit

  9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")

interacting with commits

  84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert")
  283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping")

from the btrfs-kdave tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 Jul 2019 15:29:27 +1000
Subject: [PATCH] locking/lockdep: fix up for "Rename
 lockdep_assert_held_exclusive() -> lockdep_assert_held_write()"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/btrfs/ctree.c      | 2 +-
 fs/btrfs/extent_map.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 99a585ede79d..9d1d0a926cb0 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -385,7 +385,7 @@ __tree_mod_log_insert(struct btrfs_fs_info *fs_info, struct tree_mod_elem *tm)
 	struct rb_node *parent = NULL;
 	struct tree_mod_elem *cur;
 
-	lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock);
+	lockdep_assert_held_write(&fs_info->tree_mod_log_lock);
 
 	tm->seq = btrfs_inc_tree_mod_seq(fs_info);
 
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index a73af4159495..9d30acca55e1 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -384,7 +384,7 @@ int add_extent_mapping(struct extent_map_tree *tree,
 {
 	int ret = 0;
 
-	lockdep_assert_held_exclusive(&tree->lock);
+	lockdep_assert_held_write(&tree->lock);
 
 	ret = tree_insert(&tree->map, em);
 	if (ret)
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:56     ` Thomas Gleixner
@ 2019-06-25  7:47       ` Kalle Valo
  0 siblings, 0 replies; 245+ messages in thread
From: Kalle Valo @ 2019-06-25  7:47 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

Thomas Gleixner <tglx@linutronix.de> writes:

> On Tue, 25 Jun 2019, Stephen Rothwell wrote:
>
>> Hi Kalle,
>> 
>> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
>> >
>> > Thanks for the report. Any suggestions how to handle this? Or do we let
>> > Linus take care of this?
>> 
>> Just let Linus take care of it ... mention it in the pull request ... I
>> guess DaveM needs to know, right?
>
> Ah. I didn't realize that this is a new commit in Kalle's tree. So yes
> that's the right thing to do.

Good, I'll do that then.

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:36   ` Stephen Rothwell
  2019-06-25  6:51     ` Kalle Valo
@ 2019-06-25  6:56     ` Thomas Gleixner
  2019-06-25  7:47       ` Kalle Valo
  1 sibling, 1 reply; 245+ messages in thread
From: Thomas Gleixner @ 2019-06-25  6:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kalle Valo, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

On Tue, 25 Jun 2019, Stephen Rothwell wrote:

> Hi Kalle,
> 
> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
> >
> > Thanks for the report. Any suggestions how to handle this? Or do we let
> > Linus take care of this?
> 
> Just let Linus take care of it ... mention it in the pull request ... I
> guess DaveM needs to know, right?

Ah. I didn't realize that this is a new commit in Kalle's tree. So yes
that's the right thing to do.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:36   ` Stephen Rothwell
@ 2019-06-25  6:51     ` Kalle Valo
  2019-06-25  6:56     ` Thomas Gleixner
  1 sibling, 0 replies; 245+ messages in thread
From: Kalle Valo @ 2019-06-25  6:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Thanks for the report. Any suggestions how to handle this? Or do we let
>> Linus take care of this?
>
> Just let Linus take care of it ... mention it in the pull request ...

Thanks, I'll do that.

> I guess DaveM needs to know, right?

Yeah, this commit goes from wireless-drivers-next to net-next and from
there to Linus. I'll inform Dave in my pull request.

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:23 ` Kalle Valo
  2019-06-25  6:26   ` Thomas Gleixner
@ 2019-06-25  6:36   ` Stephen Rothwell
  2019-06-25  6:51     ` Kalle Valo
  2019-06-25  6:56     ` Thomas Gleixner
  1 sibling, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-06-25  6:36 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Hi Kalle,

On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Thanks for the report. Any suggestions how to handle this? Or do we let
> Linus take care of this?

Just let Linus take care of it ... mention it in the pull request ... I guess DaveM needs to know, right?

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:23 ` Kalle Valo
@ 2019-06-25  6:26   ` Thomas Gleixner
  2019-06-25  6:36   ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Thomas Gleixner @ 2019-06-25  6:26 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

On Tue, 25 Jun 2019, Kalle Valo wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > ---
> >  drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> > index be6968454282..873fea59894f 100644
> > --- a/drivers/net/wireless/intersil/p54/txrx.c
> > +++ b/drivers/net/wireless/intersil/p54/txrx.c
> > @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
> >  
> >  	fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
> >  	if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> > -		rx_status->boottime_ns = ktime_get_boot_ns();
> > +		rx_status->boottime_ns = ktime_get_boottime_ns();
> 
> Thanks for the report. Any suggestions how to handle this? Or do we let
> Linus take care of this?

As the core changes which cause this are in tip timers/core, I can just
pick that up and be done with it. Ok?

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2019-06-25  6:04 Stephen Rothwell
@ 2019-06-25  6:23 ` Kalle Valo
  2019-06-25  6:26   ` Thomas Gleixner
  2019-06-25  6:36   ` Stephen Rothwell
  2019-07-09  0:09 ` Stephen Rothwell
  2019-07-09  3:46 ` Stephen Rothwell
  2 siblings, 2 replies; 245+ messages in thread
From: Kalle Valo @ 2019-06-25  6:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration]
>    rx_status->boottime_ns = ktime_get_boot_ns();
>                             ^~~~~~~~~~~~~~~~~
>                             ktime_get_raw_ns
>
> Caused by commit
>
>   c11c75ec784e ("p54: Support boottime in scan results")
>
> from the wireless-drivers-next tree interacting with commit
>
>   9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
>
> from the tip tree.
>
> I have added the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/net/wireless/intersil/p54/txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
>  
>  	fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
>  	if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> -		rx_status->boottime_ns = ktime_get_boot_ns();
> +		rx_status->boottime_ns = ktime_get_boottime_ns();

Thanks for the report. Any suggestions how to handle this? Or do we let
Linus take care of this?

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2019-06-25  6:04 Stephen Rothwell
  2019-06-25  6:23 ` Kalle Valo
                   ` (2 more replies)
  0 siblings, 3 replies; 245+ messages in thread
From: Stephen Rothwell @ 2019-06-25  6:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Kalle Valo, Wireless
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christian Lamparter, Jason A. Donenfeld

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration]
   rx_status->boottime_ns = ktime_get_boot_ns();
                            ^~~~~~~~~~~~~~~~~
                            ktime_get_raw_ns

Caused by commit

  c11c75ec784e ("p54: Support boottime in scan results")

from the wireless-drivers-next tree interacting with commit

  9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")

from the tip tree.

I have added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 Jun 2019 15:55:36 +1000
Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/wireless/intersil/p54/txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
index be6968454282..873fea59894f 100644
--- a/drivers/net/wireless/intersil/p54/txrx.c
+++ b/drivers/net/wireless/intersil/p54/txrx.c
@@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
 
 	fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
 	if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
-		rx_status->boottime_ns = ktime_get_boot_ns();
+		rx_status->boottime_ns = ktime_get_boottime_ns();
 
 	if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
 		p54_pspoll_workaround(priv, skb);
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2018-11-06  0:43 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2018-11-06  0:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Rutland

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

/bin/bash: scripts/atomic/check-atomics.sh: No such file or directory

Caused by commit

  8d32588077bd ("locking/atomics: Check generated headers are up-to-date")

I build with O=

I have appplied the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 6 Nov 2018 11:37:10 +1100
Subject: [PATCH] fix for "locking/atomics: Check generated headers are
 up-to-date"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 Kbuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Kbuild b/Kbuild
index 47c9fe175bd9..780048056ac5 100644
--- a/Kbuild
+++ b/Kbuild
@@ -80,7 +80,7 @@ always += old-atomics
 targets += old-atomics
 
 quiet_cmd_atomics = CALL    $<
-      cmd_atomics = $(CONFIG_SHELL) scripts/atomic/check-atomics.sh
+      cmd_atomics = $(CONFIG_SHELL) $<
 
 old-atomics: scripts/atomic/check-atomics.sh FORCE
 	$(call cmd,atomics)
-- 
2.19.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2018-08-08 23:24 Stephen Rothwell
@ 2018-08-09  9:41 ` Joerg Roedel
  0 siblings, 0 replies; 245+ messages in thread
From: Joerg Roedel @ 2018-08-09  9:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

Hi Stephen,

On Thu, Aug 09, 2018 at 09:24:20AM +1000, Stephen Rothwell wrote:
> Invalid absolute R_X86_64_32S relocation: __end_rodata_aligned
> /kisskb/src/arch/x86/boot/compressed/Makefile:127: recipe for target 'arch/x86/boot/compressed/vmlinux.relocs' failed
> 
> Caused by commit
> 
>   39d668e04eda ("x86/mm/pti: Make pti_clone_kernel_text() compile on 32 bit")

Thanks for the report! I only built the source with gcc-4.8 and gcc-7.3,
so I didn't catch this earlier. I have a fix now and will send it as a
separate reply in this thread.


Thanks,

	Joerg

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2018-08-08 23:24 Stephen Rothwell
  2018-08-09  9:41 ` Joerg Roedel
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2018-08-08 23:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joerg Roedel

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 defconfig)
failed like this:

Invalid absolute R_X86_64_32S relocation: __end_rodata_aligned
/kisskb/src/arch/x86/boot/compressed/Makefile:127: recipe for target 'arch/x86/boot/compressed/vmlinux.relocs' failed

Caused by commit

  39d668e04eda ("x86/mm/pti: Make pti_clone_kernel_text() compile on 32 bit")

This was a build using gcc 4.6.3.  the i386 defconfig also failed
like this:

Invalid absolute R_386_32 relocation: __end_rodata_aligned

They started failing on next-20180723 (which is the first -next that
contained the above commit).  Sorry that we did not notice this earlier.
At least the i386 defconfig build works with gcc 7.3.1.

You can see the full build results here:
http://kisskb.ellerman.id.au/kisskb/head/6b522b734da2950c368aae668f963b8925fb5545/

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2018-04-03 12:39 ` David Howells
@ 2018-04-03 12:42   ` Peter Zijlstra
  0 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2018-04-03 12:42 UTC (permalink / raw)
  To: David Howells
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Tue, Apr 03, 2018 at 01:39:08PM +0100, David Howells wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > I figured that since there were only a handful of users it wasn't a
> > popular API, also David very much knew of those patches changing it so
> > could easily have pulled in the special tip/sched/wait branch :/
> 
> I'm not sure I could, since I have to base on net-next.  I'm not sure what
> DaveM's policy on that is.
> 
> Also, it might've been better not to simply erase the atomic_t wait API
> immediately, but substitute wrappers for it to be removed one iteration hence.

Yeah, I know, but I really wasn't expecting new users of this thing, it
seemed like quite an exotic API with very limited users.

A well..

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2018-04-03  5:41 Stephen Rothwell
  2018-04-03  9:30 ` Peter Zijlstra
  2018-04-03 12:39 ` David Howells
@ 2018-04-03 12:41 ` David Howells
  2 siblings, 0 replies; 245+ messages in thread
From: David Howells @ 2018-04-03 12:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, David Miller, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> +	wait_var_event(&rxnet->nr_calls, !atomic_read(&rxnet->nr_calls));

I would prefer == 0 to ! as it's not really a true/false value.

But apart from that, it's looks okay and you can add my Reviewed-by.

David

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2018-04-03  5:41 Stephen Rothwell
  2018-04-03  9:30 ` Peter Zijlstra
@ 2018-04-03 12:39 ` David Howells
  2018-04-03 12:42   ` Peter Zijlstra
  2018-04-03 12:41 ` David Howells
  2 siblings, 1 reply; 245+ messages in thread
From: David Howells @ 2018-04-03 12:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: dhowells, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, David Miller, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List

Peter Zijlstra <peterz@infradead.org> wrote:

> I figured that since there were only a handful of users it wasn't a
> popular API, also David very much knew of those patches changing it so
> could easily have pulled in the special tip/sched/wait branch :/

I'm not sure I could, since I have to base on net-next.  I'm not sure what
DaveM's policy on that is.

Also, it might've been better not to simply erase the atomic_t wait API
immediately, but substitute wrappers for it to be removed one iteration hence.

David

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2018-04-03  5:41 Stephen Rothwell
@ 2018-04-03  9:30 ` Peter Zijlstra
  2018-04-03 12:39 ` David Howells
  2018-04-03 12:41 ` David Howells
  2 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2018-04-03  9:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, David Miller,
	Networking, Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells

On Tue, Apr 03, 2018 at 03:41:22PM +1000, Stephen Rothwell wrote:

> Caused by commit
> 
>   9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API")
> 
> interacting with commits
> 
>   d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race")
>   31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects")
> 
> from the net-next tree.
> 
> Haven't we figured out how to remove/change APIs yet? :-(

I figured that since there were only a handful of users it wasn't a
popular API, also David very much knew of those patches changing it so
could easily have pulled in the special tip/sched/wait branch :/

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2018-04-03  5:41 Stephen Rothwell
  2018-04-03  9:30 ` Peter Zijlstra
                   ` (2 more replies)
  0 siblings, 3 replies; 245+ messages in thread
From: Stephen Rothwell @ 2018-04-03  5:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 4619 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call':
net/rxrpc/call_object.c:661:3: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'? [-Werror=implicit-function-declaration]
   wake_up_atomic_t(&rxnet->nr_calls);
   ^~~~~~~~~~~~~~~~
   wake_up_bit
net/rxrpc/call_object.c: In function 'rxrpc_destroy_all_calls':
net/rxrpc/call_object.c:728:2: error: implicit declaration of function 'wait_on_atomic_t'; did you mean 'wait_on_bit'? [-Werror=implicit-function-declaration]
  wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
  ^~~~~~~~~~~~~~~~
  wait_on_bit
net/rxrpc/call_object.c:728:37: error: 'atomic_t_wait' undeclared (first use in this function); did you mean 'atomic_long_t'?
  wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
                                     ^~~~~~~~~~~~~
                                     atomic_long_t
net/rxrpc/call_object.c:728:37: note: each undeclared identifier is reported only once for each function it appears in
net/rxrpc/call_accept.c: In function 'rxrpc_discard_prealloc':
net/rxrpc/call_accept.c:223:4: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'? [-Werror=implicit-function-declaration]
    wake_up_atomic_t(&rxnet->nr_conns);
    ^~~~~~~~~~~~~~~~
    wake_up_bit

Caused by commit

  9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API")

interacting with commits

  d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race")
  31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects")

from the net-next tree.

Haven't we figured out how to remove/change APIs yet? :-(

That tip tree commit is now in Linus' tree (merged since I started this
morning) so the net-next tree will need the below patch (or something
similar when it is merged.

I have applied the following merge fix patch (this may need more work):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 3 Apr 2018 15:34:48 +1000
Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/rxrpc/call_accept.c | 2 +-
 net/rxrpc/call_object.c | 4 ++--
 net/rxrpc/conn_object.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index f67017dcb25e..a9a9be5519b9 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -220,7 +220,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
 		write_unlock(&rxnet->conn_lock);
 		kfree(conn);
 		if (atomic_dec_and_test(&rxnet->nr_conns))
-			wake_up_atomic_t(&rxnet->nr_conns);
+			wake_up_var(&rxnet->nr_conns);
 		tail = (tail + 1) & (size - 1);
 	}
 
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index f721c2b7e234..f6734d8cb01a 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -658,7 +658,7 @@ static void rxrpc_rcu_destroy_call(struct rcu_head *rcu)
 	kfree(call->rxtx_annotations);
 	kmem_cache_free(rxrpc_call_jar, call);
 	if (atomic_dec_and_test(&rxnet->nr_calls))
-		wake_up_atomic_t(&rxnet->nr_calls);
+		wake_up_var(&rxnet->nr_calls);
 }
 
 /*
@@ -725,5 +725,5 @@ void rxrpc_destroy_all_calls(struct rxrpc_net *rxnet)
 	write_unlock(&rxnet->call_lock);
 
 	atomic_dec(&rxnet->nr_calls);
-	wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+	wait_var_event(&rxnet->nr_calls, !atomic_read(&rxnet->nr_calls));
 }
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 0950ee3d26f5..4c77a78a252a 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -367,7 +367,7 @@ static void rxrpc_destroy_connection(struct rcu_head *rcu)
 	rxrpc_put_peer(conn->params.peer);
 
 	if (atomic_dec_and_test(&conn->params.local->rxnet->nr_conns))
-		wake_up_atomic_t(&conn->params.local->rxnet->nr_conns);
+		wake_up_var(&conn->params.local->rxnet->nr_conns);
 	rxrpc_put_local(conn->params.local);
 
 	kfree(conn);
@@ -482,6 +482,6 @@ void rxrpc_destroy_all_connections(struct rxrpc_net *rxnet)
 	/* We need to wait for the connections to be destroyed by RCU as they
 	 * pin things that we still need to get rid of.
 	 */
-	wait_on_atomic_t(&rxnet->nr_conns, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+	wait_var_event(&rxnet->nr_conns, !atomic_read(&rxnet->nr_conns));
 	_leave("");
 }
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08 12:14     ` Stephen Rothwell
@ 2017-11-09  6:18       ` Ingo Molnar
  0 siblings, 0 replies; 245+ messages in thread
From: Ingo Molnar @ 2017-11-09  6:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Josh Poimboeuf, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Note, I created a commit out of this fix, with your SOB - let me know if you have 
> > any objections.
> 
> Only a small nit - I didn't bisect it, I just figured it out by
> inspection.  Unfortunately, I don't have time to do bisections while
> building linux-next. :-(
> 
> Not a biggie, though.  Thanks for sorting this out.

Yeah, so while I knew that you didn't do the bisection the usual way, you still 
got it right nevertheless, so the tag is well deserved! I'll add it as a 
"Commit-identified-by" tag next time perhaps.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  9:18   ` Ingo Molnar
  2017-11-08 12:14     ` Stephen Rothwell
  2017-11-08 13:17     ` Josh Poimboeuf
@ 2017-11-09  3:03     ` Stephen Rothwell
  2 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-11-09  3:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Josh Poimboeuf, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:  
> > 
> > Does this fix it?
> > 
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 6aaed251b4ed..0f94af3ccaaa 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -27,7 +27,7 @@ all: $(OBJTOOL)
> >  
> >  INCLUDES := -I$(srctree)/tools/include \
> >  	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> > -	    -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> > +	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> >  WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> >  CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> >  LDFLAGS  += -lelf $(LIBSUBCMD)  
> 
> Note, I created a commit out of this fix, with your SOB - let me know if you have 
> any objections.

I applied this patch to linux-next today after the tip tree merge.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  9:18   ` Ingo Molnar
  2017-11-08 12:14     ` Stephen Rothwell
@ 2017-11-08 13:17     ` Josh Poimboeuf
  2017-11-09  3:03     ` Stephen Rothwell
  2 siblings, 0 replies; 245+ messages in thread
From: Josh Poimboeuf @ 2017-11-08 13:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Wed, Nov 08, 2017 at 10:18:28AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > > Presumably caused by commit
> > > 
> > >   6a77cff819ae ("objtool: Move synced files to their original relative locations")
> > > 
> > > If it matters, this is a cross compilation (PowerPC host) using O= .
> > > 
> > > I have used the tip tree from next-20171107 for today.
> > 
> > Hi Stephen,
> > 
> > Does this fix it?
> > 
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 6aaed251b4ed..0f94af3ccaaa 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -27,7 +27,7 @@ all: $(OBJTOOL)
> >  
> >  INCLUDES := -I$(srctree)/tools/include \
> >  	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> > -	    -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> > +	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> >  WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> >  CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> >  LDFLAGS  += -lelf $(LIBSUBCMD)
> 
> Note, I created a commit out of this fix, with your SOB - let me know if you have 
> any objections.

Looks good, thanks Ingo!

-- 
Josh

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  9:18   ` Ingo Molnar
@ 2017-11-08 12:14     ` Stephen Rothwell
  2017-11-09  6:18       ` Ingo Molnar
  2017-11-08 13:17     ` Josh Poimboeuf
  2017-11-09  3:03     ` Stephen Rothwell
  2 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2017-11-08 12:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Josh Poimboeuf, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> Note, I created a commit out of this fix, with your SOB - let me know if you have 
> any objections.

Only a small nit - I didn't bisect it, I just figured it out by
inspection.  Unfortunately, I don't have time to do bisections while
building linux-next. :-(

Not a biggie, though.  Thanks for sorting this out.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  3:01 ` Josh Poimboeuf
  2017-11-08  7:35   ` Stephen Rothwell
@ 2017-11-08  9:18   ` Ingo Molnar
  2017-11-08 12:14     ` Stephen Rothwell
                       ` (2 more replies)
  1 sibling, 3 replies; 245+ messages in thread
From: Ingo Molnar @ 2017-11-08  9:18 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List


* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > Presumably caused by commit
> > 
> >   6a77cff819ae ("objtool: Move synced files to their original relative locations")
> > 
> > If it matters, this is a cross compilation (PowerPC host) using O= .
> > 
> > I have used the tip tree from next-20171107 for today.
> 
> Hi Stephen,
> 
> Does this fix it?
> 
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 6aaed251b4ed..0f94af3ccaaa 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -27,7 +27,7 @@ all: $(OBJTOOL)
>  
>  INCLUDES := -I$(srctree)/tools/include \
>  	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> -	    -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> +	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
>  WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
>  CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
>  LDFLAGS  += -lelf $(LIBSUBCMD)

Note, I created a commit out of this fix, with your SOB - let me know if you have 
any objections.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  3:01 ` Josh Poimboeuf
@ 2017-11-08  7:35   ` Stephen Rothwell
  2017-11-08  9:18   ` Ingo Molnar
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-11-08  7:35 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

Hi Josh,

On Tue, 7 Nov 2017 21:01:52 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > Presumably caused by commit
> > 
> >   6a77cff819ae ("objtool: Move synced files to their original relative locations")
> > 
> > If it matters, this is a cross compilation (PowerPC host) using O= .
> > 
> > I have used the tip tree from next-20171107 for today.  
> 
> Hi Stephen,
> 
> Does this fix it?
> 
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 6aaed251b4ed..0f94af3ccaaa 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -27,7 +27,7 @@ all: $(OBJTOOL)
>  
>  INCLUDES := -I$(srctree)/tools/include \
>  	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> -	    -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> +	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
>  WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
>  CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
>  LDFLAGS  += -lelf $(LIBSUBCMD)

Yes, thanks.

Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-08  2:47 Stephen Rothwell
@ 2017-11-08  3:01 ` Josh Poimboeuf
  2017-11-08  7:35   ` Stephen Rothwell
  2017-11-08  9:18   ` Ingo Molnar
  0 siblings, 2 replies; 245+ messages in thread
From: Josh Poimboeuf @ 2017-11-08  3:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> Presumably caused by commit
> 
>   6a77cff819ae ("objtool: Move synced files to their original relative locations")
> 
> If it matters, this is a cross compilation (PowerPC host) using O= .
> 
> I have used the tip tree from next-20171107 for today.

Hi Stephen,

Does this fix it?

diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 6aaed251b4ed..0f94af3ccaaa 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -27,7 +27,7 @@ all: $(OBJTOOL)
 
 INCLUDES := -I$(srctree)/tools/include \
 	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-	    -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
+	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
 WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
 CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
 LDFLAGS  += -lelf $(LIBSUBCMD)

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-11-08  2:47 Stephen Rothwell
  2017-11-08  3:01 ` Josh Poimboeuf
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2017-11-08  2:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josh Poimboeuf

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from orc_dump.c:19:0:
orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
 #include <asm/orc_types.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.orc_dump.o.tmp': No such file or directory
tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/orc_dump.o' failed
In file included from orc_gen.c:21:0:
orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
 #include <asm/orc_types.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.orc_gen.o.tmp': No such file or directory
tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/orc_gen.o' failed
In file included from check.h:25:0,
                 from builtin-check.c:30:
orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
 #include <asm/orc_types.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
In file included from check.h:25:0,
                 from builtin-orc.c:30:
orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
 #include <asm/orc_types.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.builtin-check.o.tmp': No such file or directory
tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o' failed
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.builtin-orc.o.tmp': No such file or directory
tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-orc.o' failed
In file included from check.h:25:0,
                 from check.c:21:
orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
 #include <asm/orc_types.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.check.o.tmp': No such file or directory
tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/check.o' failed
arch/x86/decode.c:22:10: fatal error: asm/insn.h: No such file or directory
 #include <asm/insn.h>
          ^~~~~~~~~~~~
compilation terminated.
mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/.decode.o.tmp': No such file or directory

Presumably caused by commit

  6a77cff819ae ("objtool: Move synced files to their original relative locations")

If it matters, this is a cross compilation (PowerPC host) using O= .

I have used the tip tree from next-20171107 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-11-01 10:51 Stephen Rothwell
@ 2017-11-01 14:32 ` Kees Cook
  0 siblings, 0 replies; 245+ messages in thread
From: Kees Cook @ 2017-11-01 14:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Wed, Nov 1, 2017 at 3:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/workqueue.h:8:0,
>                  from include/linux/srcu.h:34,
>                  from include/linux/notifier.h:15,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:779,
>                  from include/linux/gfp.h:5,
>                  from include/linux/umh.h:4,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from drivers/net/ethernet/chelsio/cxgb/common.h:43,
>                  from drivers/net/ethernet/chelsio/cxgb/sge.c:39:
> drivers/net/ethernet/chelsio/cxgb/sge.c: In function 't1_sge_create':
> include/linux/timer.h:176:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>    __setup_timer(timer, (TIMER_FUNC_TYPE)callback,  \
>                         ^
> include/linux/timer.h:122:25: note: in definition of macro '__setup_timer'
>    (_timer)->function = (_fn);    \
>                          ^
> drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
>    timer_setup(&sge->espibug_timer,
>    ^
> drivers/net/ethernet/chelsio/cxgb/sge.c:2082:31: warning: comparison between pointer and integer
>         adapter->params.nports > 1 ? espibug_workaround_t204 : espibug_workaround,
>                                ^
> include/linux/timer.h:122:25: note: in definition of macro '__setup_timer'
>    (_timer)->function = (_fn);    \
>                          ^
> drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
>    timer_setup(&sge->espibug_timer,
>    ^
> include/linux/timer.h:122:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
>    (_timer)->function = (_fn);    \
>                       ^
> include/linux/timer.h:176:3: note: in expansion of macro '__setup_timer'
>    __setup_timer(timer, (TIMER_FUNC_TYPE)callback,  \
>    ^
> drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
>    timer_setup(&sge->espibug_timer,
>    ^
>
> and another similar.
>
> Caused by commit
>
>   cacd2b3fb981 ("chelsio: Convert timers to use timer_setup()")
>
> from te net-next tree interacting with commit
>
>   52f737c2da40 ("timer: Provide wrappers safe for use with LOCKDEP")
>
> from the tip tree.
>
> Looks like the LOCKDEP sage version of timer_setup() needs to put
> parentheses around the usages of its parameters?

Ugh, yup. Thanks for the catch. I have no idea why I didn't see this
in my own builds.

-Kees

>
> --
> Cheers,
> Stephen Rothwell
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-11-01 10:51 Stephen Rothwell
  2017-11-01 14:32 ` Kees Cook
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2017-11-01 10:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from include/linux/workqueue.h:8:0,
                 from include/linux/srcu.h:34,
                 from include/linux/notifier.h:15,
                 from include/linux/memory_hotplug.h:6,
                 from include/linux/mmzone.h:779,
                 from include/linux/gfp.h:5,
                 from include/linux/umh.h:4,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from drivers/net/ethernet/chelsio/cxgb/common.h:43,
                 from drivers/net/ethernet/chelsio/cxgb/sge.c:39:
drivers/net/ethernet/chelsio/cxgb/sge.c: In function 't1_sge_create':
include/linux/timer.h:176:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   __setup_timer(timer, (TIMER_FUNC_TYPE)callback,  \
                        ^
include/linux/timer.h:122:25: note: in definition of macro '__setup_timer'
   (_timer)->function = (_fn);    \
                         ^
drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
   timer_setup(&sge->espibug_timer,
   ^
drivers/net/ethernet/chelsio/cxgb/sge.c:2082:31: warning: comparison between pointer and integer
        adapter->params.nports > 1 ? espibug_workaround_t204 : espibug_workaround,
                               ^
include/linux/timer.h:122:25: note: in definition of macro '__setup_timer'
   (_timer)->function = (_fn);    \
                         ^
drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
   timer_setup(&sge->espibug_timer,
   ^
include/linux/timer.h:122:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
   (_timer)->function = (_fn);    \
                      ^
include/linux/timer.h:176:3: note: in expansion of macro '__setup_timer'
   __setup_timer(timer, (TIMER_FUNC_TYPE)callback,  \
   ^
drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup'
   timer_setup(&sge->espibug_timer,
   ^

and another similar.

Caused by commit

  cacd2b3fb981 ("chelsio: Convert timers to use timer_setup()")

from te net-next tree interacting with commit

  52f737c2da40 ("timer: Provide wrappers safe for use with LOCKDEP")

from the tip tree.

Looks like the LOCKDEP sage version of timer_setup() needs to put
parentheses around the usages of its parameters?

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-06-28  3:43 Stephen Rothwell
  2017-06-28  4:00 ` jeffy
@ 2017-07-03  3:01 ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-07-03  3:01 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Gustavo Padovan
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jeffy Chen

Hi all,

With the merge window opening, just a reminder that this semantic
conflict still exists.

On Wed, 28 Jun 2017 13:43:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
>  static int hidp_session_wake_function(wait_queue_t *wait,
>                                        ^
> In file included from include/linux/mmzone.h:9:0,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from net/bluetooth/hidp/core.c:25:
> net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
> net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function)
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>                               ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>    .func  = function,     \
>             ^
> net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>                               ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>    .func  = function,     \
>             ^
> 
> Caused by commit
> 
>   ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
> 
> interacting with commit
> 
>   5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread")
> 
> from the bluetooth tree.  I should have fixed this up in the merge, sorry.
> I added the following merge fix for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Jun 2017 13:36:04 +1000
> Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
>  wait_queue_entry_t"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  net/bluetooth/hidp/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 472b3907b1b0..002743ea509c 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session)
>  	smp_mb__after_atomic();
>  }
>  
> -static int hidp_session_wake_function(wait_queue_t *wait,
> +static int hidp_session_wake_function(wait_queue_entry_t *wait,
>  				      unsigned int mode,
>  				      int sync, void *key)
>  {
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-06-28  4:00 ` jeffy
@ 2017-06-28  4:24   ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-06-28  4:24 UTC (permalink / raw)
  To: jeffy
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Gustavo Padovan, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi jeffy,

On Wed, 28 Jun 2017 12:00:19 +0800 jeffy <jeffy.chen@rock-chips.com> wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar <mingo@kernel.org>
> Date:   Sun Mar 5 10:33:16 2017 +0100
> 
>      sched/wait: Standardize internal naming of wait-queue entries
> 
> 
> changed wait_queue_entry_t to struct wait_queue_entry, and also wait to 
> wq_entry, maybe we should do it too?

Sure, but that can be done later.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-06-28  3:43 Stephen Rothwell
@ 2017-06-28  4:00 ` jeffy
  2017-06-28  4:24   ` Stephen Rothwell
  2017-07-03  3:01 ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: jeffy @ 2017-06-28  4:00 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Gustavo Padovan
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Stephen,

On 06/28/2017 11:43 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
>   static int hidp_session_wake_function(wait_queue_t *wait,
>                                         ^
> In file included from include/linux/mmzone.h:9:0,
>                   from include/linux/gfp.h:5,
>                   from include/linux/kmod.h:22,
>                   from include/linux/module.h:13,
>                   from net/bluetooth/hidp/core.c:25:
> net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
> net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function)
>    DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>                                ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>     .func  = function,     \
>              ^
> net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in
>    DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>                                ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>     .func  = function,     \
>              ^
>
> Caused by commit
>
>    ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
>
> interacting with commit
>
>    5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread")
>
> from the bluetooth tree.  I should have fixed this up in the merge, sorry.
> I added the following merge fix for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Jun 2017 13:36:04 +1000
> Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
>   wait_queue_entry_t"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   net/bluetooth/hidp/core.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 472b3907b1b0..002743ea509c 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session)
>   	smp_mb__after_atomic();
>   }
>
> -static int hidp_session_wake_function(wait_queue_t *wait,
> +static int hidp_session_wake_function(wait_queue_entry_t *wait,

thanx for fixing this. and i saw

commit 50816c48997af857d4bab3dca1aba90339705e96
Author: Ingo Molnar <mingo@kernel.org>
Date:   Sun Mar 5 10:33:16 2017 +0100

     sched/wait: Standardize internal naming of wait-queue entries


changed wait_queue_entry_t to struct wait_queue_entry, and also wait to 
wq_entry, maybe we should do it too?

>   				      unsigned int mode,
>   				      int sync, void *key)
>   {
>

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-06-28  3:43 Stephen Rothwell
  2017-06-28  4:00 ` jeffy
  2017-07-03  3:01 ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-06-28  3:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Gustavo Padovan
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jeffy Chen

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
 static int hidp_session_wake_function(wait_queue_t *wait,
                                       ^
In file included from include/linux/mmzone.h:9:0,
                 from include/linux/gfp.h:5,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from net/bluetooth/hidp/core.c:25:
net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function)
  DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
                              ^
include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
   .func  = function,     \
            ^
net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in
  DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
                              ^
include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
   .func  = function,     \
            ^

Caused by commit

  ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")

interacting with commit

  5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread")

from the bluetooth tree.  I should have fixed this up in the merge, sorry.
I added the following merge fix for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 28 Jun 2017 13:36:04 +1000
Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
 wait_queue_entry_t"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/bluetooth/hidp/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 472b3907b1b0..002743ea509c 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session)
 	smp_mb__after_atomic();
 }
 
-static int hidp_session_wake_function(wait_queue_t *wait,
+static int hidp_session_wake_function(wait_queue_entry_t *wait,
 				      unsigned int mode,
 				      int sync, void *key)
 {
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-05-02  3:17 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2017-05-02  3:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Ming Lei, Jens Axboe

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/nvdimm/pmem.c: In function 'pmem_freeze_queue':
drivers/nvdimm/pmem.c:237:2: error: implicit declaration of function 'blk_mq_freeze_queue_start' [-Werror=implicit-function-declaration]
  blk_mq_freeze_queue_start(q);
  ^

Caused by commit

  71389703839e ("mm, zone_device: Replace {get, put}_zone_device_page() with a single reference to fix pmem crash")

interacting with commit

  1671d522cdd9 ("block: rename blk_mq_freeze_queue_start()")

from Linus' tree.

I have applied the merge fix patch below.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 May 2017 13:09:41 +1000
Subject: [PATCH] mm, zone_device: merge fix up for blk_mq_freeze_queue_start()
 rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/nvdimm/pmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index fb7bbc79ac26..fbc640bf06b0 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -234,7 +234,7 @@ static void pmem_release_queue(void *q)
 
 static void pmem_freeze_queue(void *q)
 {
-	blk_mq_freeze_queue_start(q);
+	blk_freeze_queue_start(q);
 }
 
 static void pmem_release_disk(void *disk)
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-04-24  3:32 Stephen Rothwell
@ 2017-04-24  5:31 ` Ingo Molnar
  0 siblings, 0 replies; 245+ messages in thread
From: Ingo Molnar @ 2017-04-24  5:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Steven Rostedt


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/tracepoint.c: In function 'tracepoint_remove_func':
> kernel/tracepoint.c:253:4: error: implicit declaration of function 'static_key_slow_dec_cpuslocked' [-Werror=implicit-function-declaration]
>     static_key_slow_dec_cpuslocked(&tp->key);
>     ^
> 
> Caused by commit
> 
>   24db7a671bd5 ("trace/perf: Cure hotplug lock ordering issues")
> 
> static_key_slow_dec_cpuslocked() is only defined if HAVE_JUMP_LABEL is
> set - which is only defined if defined(CC_HAVE_ASM_GOTO) &&
> defined(CONFIG_JUMP_LABEL).  CONFIG_JUMP_LABEL is not set for this build.
> 
> I wasn't sure if just adding
> 
>   #define static_key_slow_dec_cpuslocked static_key_slow_dec
> 
> in the !HAVE_JUMP_LABEL case in include/linux/jump_label.h would be
> sufficient, so I have reverted that commit for today.

Both are fine, thanks Stephen! It's all fixed up in tip:auto-latest as well.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-04-24  3:32 Stephen Rothwell
  2017-04-24  5:31 ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2017-04-24  3:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Steven Rostedt

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

kernel/tracepoint.c: In function 'tracepoint_remove_func':
kernel/tracepoint.c:253:4: error: implicit declaration of function 'static_key_slow_dec_cpuslocked' [-Werror=implicit-function-declaration]
    static_key_slow_dec_cpuslocked(&tp->key);
    ^

Caused by commit

  24db7a671bd5 ("trace/perf: Cure hotplug lock ordering issues")

static_key_slow_dec_cpuslocked() is only defined if HAVE_JUMP_LABEL is
set - which is only defined if defined(CC_HAVE_ASM_GOTO) &&
defined(CONFIG_JUMP_LABEL).  CONFIG_JUMP_LABEL is not set for this build.

I wasn't sure if just adding

  #define static_key_slow_dec_cpuslocked static_key_slow_dec

in the !HAVE_JUMP_LABEL case in include/linux/jump_label.h would be
sufficient, so I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2017-04-05  3:36 Stephen Rothwell
@ 2017-04-05  7:24 ` Mikko Perttunen
  0 siblings, 0 replies; 245+ messages in thread
From: Mikko Perttunen @ 2017-04-05  7:24 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Thierry Reding
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Arto Merilainen, Alexandre Courbot

On 05.04.2017 06:36, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/built-in.o:(__tracepoints+0x64): multiple definition of `__tracepoint_remove_device_from_group'
> drivers/iommu/built-in.o:(__tracepoints+0x64): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x3c): multiple definition of `__tracepoint_detach_device_from_domain'
> drivers/iommu/built-in.o:(__tracepoints+0x3c): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x0): multiple definition of `__tracepoint_io_page_fault'
> drivers/iommu/built-in.o:(__tracepoints+0x0): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x78): multiple definition of `__tracepoint_add_device_to_group'
> drivers/iommu/built-in.o:(__tracepoints+0x78): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x14): multiple definition of `__tracepoint_unmap'
> drivers/iommu/built-in.o:(__tracepoints+0x14): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x28): multiple definition of `__tracepoint_map'
> drivers/iommu/built-in.o:(__tracepoints+0x28): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x50): multiple definition of `__tracepoint_attach_device_to_domain'
> drivers/iommu/built-in.o:(__tracepoints+0x50): first defined here
>
> The tip tree has not changed since yesterday.  However, reverting
> the drm-tegra tree fixes the build problem.  So there is some interaction
> between the tip tree and today's drm-tegra tree.
>
> So for now, I have reverted the merge of the drm-tegra tree.
>

Looks like this is caused by my patch to add IOMMU support to Host1x. 
I'm confused by how it doesn't appear on ARMv8, though. The cause is 
that host1x/dev.c defines CREATE_TRACE_POINTS and includes 
trace/events/host1x.h, which is fine. However, it then also includes, 
among other local files, dev.h. This used to be fine, but my patch adds 
an include of linux/iommu.h to dev.h, so we get this failure. I'll post 
a fix shortly.

Thanks,
Mikko.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2017-04-05  3:36 Stephen Rothwell
  2017-04-05  7:24 ` Mikko Perttunen
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2017-04-05  3:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Thierry Reding
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Arto Merilainen, Alexandre Courbot, Mikko Perttunen

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/built-in.o:(__tracepoints+0x64): multiple definition of `__tracepoint_remove_device_from_group'
drivers/iommu/built-in.o:(__tracepoints+0x64): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x3c): multiple definition of `__tracepoint_detach_device_from_domain'
drivers/iommu/built-in.o:(__tracepoints+0x3c): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x0): multiple definition of `__tracepoint_io_page_fault'
drivers/iommu/built-in.o:(__tracepoints+0x0): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x78): multiple definition of `__tracepoint_add_device_to_group'
drivers/iommu/built-in.o:(__tracepoints+0x78): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x14): multiple definition of `__tracepoint_unmap'
drivers/iommu/built-in.o:(__tracepoints+0x14): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x28): multiple definition of `__tracepoint_map'
drivers/iommu/built-in.o:(__tracepoints+0x28): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x50): multiple definition of `__tracepoint_attach_device_to_domain'
drivers/iommu/built-in.o:(__tracepoints+0x50): first defined here

The tip tree has not changed since yesterday.  However, reverting
the drm-tegra tree fixes the build problem.  So there is some interaction
between the tip tree and today's drm-tegra tree.

So for now, I have reverted the merge of the drm-tegra tree.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-12-07 18:56       ` Ingo Molnar
@ 2016-12-07 20:32         ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-12-07 20:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Arnaldo Carvalho de Melo,
	Peter Foley, Wang Nan, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

Hi all,

On Wed, 7 Dec 2016 19:56:32 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > I'll push it today, will stop processing other stuff now and prepare a
> > pull request,  
> 
> Thanks - I pushed the fixes towards linux-next, so tomorrow's (today's) linux-next 
> build should not trigger this build race.

Thanks for the quick response.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-12-07 14:49     ` Arnaldo Carvalho de Melo
@ 2016-12-07 18:56       ` Ingo Molnar
  2016-12-07 20:32         ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2016-12-07 18:56 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Jiri Olsa, Stephen Rothwell, Arnaldo Carvalho de Melo,
	Peter Foley, Wang Nan, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel


* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Wed, Dec 07, 2016 at 09:12:15AM +0100, Jiri Olsa escreveu:
> > On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote:
> > 
> > SNIP
> > 
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > failed like this:
> > > > 
> > > >   LINK     /home/sfr/next/perf/fixdep
> > > > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> > > > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> > > > 
> > > > $ ls -l /home/sfr/next/perf/fixdep
> > > > -rwxr-xr-x 1 sfr users 71104 Dec  7 12:26 /home/sfr/next/perf/fixdep
> > > > 
> > > > I am not sure what caused this, but redoing the build succeeded, so I
> > > > have just filed this report and left it for today.
> > 
> > this seems to be the rare race issue caused by missing fixdep dependency,
> > caused probably by recompiling of fixdep because of its change in the merge
> > 
> > Arnaldo already carries a fix for this in his latest perf/core, where
> > we moved the fixdep compilation on top of everything to kill any future
> > race due to missing fixdep dependency
> 
> I'll push it today, will stop processing other stuff now and prepare a
> pull request,

Thanks - I pushed the fixes towards linux-next, so tomorrow's (today's) linux-next 
build should not trigger this build race.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-12-07  8:12   ` Jiri Olsa
@ 2016-12-07 14:49     ` Arnaldo Carvalho de Melo
  2016-12-07 18:56       ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-12-07 14:49 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Ingo Molnar, Stephen Rothwell, Arnaldo Carvalho de Melo,
	Peter Foley, Wang Nan, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

Em Wed, Dec 07, 2016 at 09:12:15AM +0100, Jiri Olsa escreveu:
> On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote:
> 
> SNIP
> 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > failed like this:
> > > 
> > >   LINK     /home/sfr/next/perf/fixdep
> > > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> > > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> > > 
> > > $ ls -l /home/sfr/next/perf/fixdep
> > > -rwxr-xr-x 1 sfr users 71104 Dec  7 12:26 /home/sfr/next/perf/fixdep
> > > 
> > > I am not sure what caused this, but redoing the build succeeded, so I
> > > have just filed this report and left it for today.
> 
> this seems to be the rare race issue caused by missing fixdep dependency,
> caused probably by recompiling of fixdep because of its change in the merge
> 
> Arnaldo already carries a fix for this in his latest perf/core, where
> we moved the fixdep compilation on top of everything to kill any future
> race due to missing fixdep dependency

I'll push it today, will stop processing other stuff now and prepare a
pull request,

- Arnaldo
 
> thanks,
> jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-12-07  7:45 ` Ingo Molnar
@ 2016-12-07  8:12   ` Jiri Olsa
  2016-12-07 14:49     ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 245+ messages in thread
From: Jiri Olsa @ 2016-12-07  8:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Arnaldo Carvalho de Melo, Peter Foley,
	Wang Nan, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote:

SNIP

> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > failed like this:
> > 
> >   LINK     /home/sfr/next/perf/fixdep
> > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> > 
> > $ ls -l /home/sfr/next/perf/fixdep
> > -rwxr-xr-x 1 sfr users 71104 Dec  7 12:26 /home/sfr/next/perf/fixdep
> > 
> > I am not sure what caused this, but redoing the build succeeded, so I
> > have just filed this report and left it for today.

this seems to be the rare race issue caused by missing fixdep dependency,
caused probably by recompiling of fixdep because of its change in the merge

Arnaldo already carries a fix for this in his latest perf/core, where
we moved the fixdep compilation on top of everything to kill any future
race due to missing fixdep dependency

thanks,
jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-12-07  1:37 Stephen Rothwell
@ 2016-12-07  7:45 ` Ingo Molnar
  2016-12-07  8:12   ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2016-12-07  7:45 UTC (permalink / raw)
  To: Stephen Rothwell, Arnaldo Carvalho de Melo, Jiri Olsa,
	Peter Foley, Wang Nan
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel


Cc:-ing Arnaldo, Jiri, Wang Nan and Peter Foley - bug report quoted below.

This bug/race might have been introduced in the latest tooling bits:

  34c4a42791bb Merge tag 'perf-core-for-mingo-20161205' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core

Which included these build system changes:

triton:~/tip> gll 78987584de42..perf/core
34c4a42791bb Merge tag 'perf-core-for-mingo-20161205' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
bec60e50af83 perf annotate: Show raw form for jump instruction with indirect target
d4dcadec43de perf tools: Add non config targets
207da4739e3e perf tools: Cleanup build directory before each test
0b4d4b076251 perf tools: Move python/perf.so target into rules area
5c319a67b13d perf tools: Move install-gtk target into rules area
2fedf79b69cf tools build: Move tabs to spaces where suitable
a5ba0a1a5af3 tools build: Make the .cmd file more readable
edd695b032ba perf clang: Compile BPF script using builtin clang support
5e08a76525b8 perf clang: Support compile IR to BPF object and add testcase
e67d52d411c3 perf clang: Update test case to use real BPF script
a9495fe9dc63 perf clang: Allow passing CFLAGS to builtin clang
77dfa84a843c perf clang: Use real file system for #include
00b86691c77c perf clang: Add builtin clang support ant test case
d58ac0bf8d1e perf build: Add clang and llvm compile and linking support
c7fb4f62e2a9 tools build: Add feature detection for clang
cb40d55b595c tools build: Add feature detection for LLVM
2bd42de0e196 perf llvm: Extract helpers in llvm-utils.c
8ad85e9e6fda perf tools: Pass context to perf hook functions
baa1973ebcf6 tools build: Fix objtool build with clang
1cd6472e3f8d tools build: Make fixdep parsing wait for last target

Thanks,

	Ingo


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> failed like this:
> 
>   LINK     /home/sfr/next/perf/fixdep
> /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> 
> $ ls -l /home/sfr/next/perf/fixdep
> -rwxr-xr-x 1 sfr users 71104 Dec  7 12:26 /home/sfr/next/perf/fixdep
> 
> I am not sure what caused this, but redoing the build succeeded, so I
> have just filed this report and left it for today.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-12-07  1:37 Stephen Rothwell
  2016-12-07  7:45 ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2016-12-07  1:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
failed like this:

  LINK     /home/sfr/next/perf/fixdep
/bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed

$ ls -l /home/sfr/next/perf/fixdep
-rwxr-xr-x 1 sfr users 71104 Dec  7 12:26 /home/sfr/next/perf/fixdep

I am not sure what caused this, but redoing the build succeeded, so I
have just filed this report and left it for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-11-17  3:22 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-11-17  3:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking
  Cc: linux-next, linux-kernel, Christian Borntraeger, Eric Dumazet

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

net/core/dev.c: In function 'sk_busy_loop':
net/core/dev.c:5065:3: error: implicit declaration of function 'cpu_relax_lowlatency' [-Werror=implicit-function-declaration]
   cpu_relax_lowlatency();
   ^

Caused by commit

  5bd0b85ba8bb ("locking/core, arch: Remove cpu_relax_lowlatency()")

interacting with commit

  217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")

from the net-next tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 17 Nov 2016 14:13:05 +1100
Subject: [PATCH] net: busy-poll: fix up for cpu_relax_lowlatency() removal

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d29d538ec5ad..6b9f8eb55b62 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5062,7 +5062,7 @@ bool sk_busy_loop(struct sock *sk, int nonblock)
 				return rc;
 			goto restart;
 		}
-		cpu_relax_lowlatency();
+		cpu_relax();
 	}
 	if (napi_poll)
 		busy_poll_stop(napi, have_poll_lock);
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-09-29 15:54   ` Chen, Yu C
@ 2016-09-29 20:50     ` Rafael J. Wysocki
  0 siblings, 0 replies; 245+ messages in thread
From: Rafael J. Wysocki @ 2016-09-29 20:50 UTC (permalink / raw)
  To: Chen, Yu C
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Denys Vlasenko

On Thursday, September 29, 2016 03:54:24 PM Chen, Yu C wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Sent: Thursday, September 29, 2016 8:25 PM
> > To: Stephen Rothwell
> > Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux-
> > next@vger.kernel.org; linux-kernel@vger.kernel.org; Denys Vlasenko; Chen, Yu
> > C
> > Subject: Re: linux-next: build failure after merge of the tip tree
> > 
> > On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the tip tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> > > arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of
> > 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> > pointer-types]
> > >   get_e820_md5(&e820_saved, buf);
> > >                ^
> > > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> > but argument is of type 'struct e820map **'
> > >  static int get_e820_md5(struct e820map *map, void *buf)
> > >             ^
> > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> > > arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of
> > 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> > pointer-types]
> > >   ret = get_e820_md5(&e820_saved, result);
> > >                      ^
> > > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> > but argument is of type 'struct e820map **'
> > >  static int get_e820_md5(struct e820map *map, void *buf)
> > >             ^
> > >
> > > Caused by commit
> > >
> > >   475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic
> > > storage")
> > >
> > > interacting with commit
> > >
> > >   6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5
> > > digest")
> > >
> > > from the pm tree.
> > >
> > > I have applied the following merge fix patch:
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 29 Sep 2016 13:13:45 +1000
> > > Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved
> > > changing
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  arch/x86/power/hibernate_64.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/power/hibernate_64.c
> > > b/arch/x86/power/hibernate_64.c index 72f2c9531b03..904048f7a9c9
> > > 100644
> > > --- a/arch/x86/power/hibernate_64.c
> > > +++ b/arch/x86/power/hibernate_64.c
> > > @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void
> > > *buf)
> > >
> > >  static void hibernation_e820_save(void *buf)  {
> > > -	get_e820_md5(&e820_saved, buf);
> > > +	get_e820_md5(e820_saved, buf);
> > >  }
> > >
> > >  static bool hibernation_e820_mismatch(void *buf) @@ -246,7 +246,7 @@
> > > static bool hibernation_e820_mismatch(void *buf)
> > >  	if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> > >  		return false;
> > >
> > > -	ret = get_e820_md5(&e820_saved, result);
> > > +	ret = get_e820_md5(e820_saved, result);
> > >  	if (ret)
> > >  		return true;
> > >
> > >
> > 
> > Looks good to me, thanks Stephen!
> > 
> > Rafael
> Thanks for the fix!
> 
> I made a double check of the patch :
> "x86/e820: Prepare e280 code for switch to dynamic storage"
> It looks like this patch has reallocate the e820 & e820_save to their actual size:
> +	size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820->nr_map;
> +	n = kmalloc(size, GFP_KERNEL);
> 
> however the previous patch to verify the md5 hash during hibernation will
> use the original e820_map structure by sizeof(struct e820map), which might 
> read invalid value after the latest patch applied. I think I need to modify the 
> hibernation e820 checking patch to only generate  md5 digest based on the actual 
> e820_save size by sizeof(struct e820entry) * e820->nr_map.
> 
> I don't have a machine in hand now, will test later and give feedback later. Thanks again!

OK, dropping the hibernation patch for now.

I'll wait for an update on top of 4.9-rc1.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 245+ messages in thread

* RE: linux-next: build failure after merge of the tip tree
  2016-09-29 12:25 ` Rafael J. Wysocki
@ 2016-09-29 15:54   ` Chen, Yu C
  2016-09-29 20:50     ` Rafael J. Wysocki
  0 siblings, 1 reply; 245+ messages in thread
From: Chen, Yu C @ 2016-09-29 15:54 UTC (permalink / raw)
  To: Rafael J. Wysocki, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Denys Vlasenko

Hi,

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Thursday, September 29, 2016 8:25 PM
> To: Stephen Rothwell
> Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org; Denys Vlasenko; Chen, Yu
> C
> Subject: Re: linux-next: build failure after merge of the tip tree
> 
> On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> > arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of
> 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> pointer-types]
> >   get_e820_md5(&e820_saved, buf);
> >                ^
> > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> but argument is of type 'struct e820map **'
> >  static int get_e820_md5(struct e820map *map, void *buf)
> >             ^
> > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> > arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of
> 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> pointer-types]
> >   ret = get_e820_md5(&e820_saved, result);
> >                      ^
> > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> but argument is of type 'struct e820map **'
> >  static int get_e820_md5(struct e820map *map, void *buf)
> >             ^
> >
> > Caused by commit
> >
> >   475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic
> > storage")
> >
> > interacting with commit
> >
> >   6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5
> > digest")
> >
> > from the pm tree.
> >
> > I have applied the following merge fix patch:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 29 Sep 2016 13:13:45 +1000
> > Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved
> > changing
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  arch/x86/power/hibernate_64.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/power/hibernate_64.c
> > b/arch/x86/power/hibernate_64.c index 72f2c9531b03..904048f7a9c9
> > 100644
> > --- a/arch/x86/power/hibernate_64.c
> > +++ b/arch/x86/power/hibernate_64.c
> > @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void
> > *buf)
> >
> >  static void hibernation_e820_save(void *buf)  {
> > -	get_e820_md5(&e820_saved, buf);
> > +	get_e820_md5(e820_saved, buf);
> >  }
> >
> >  static bool hibernation_e820_mismatch(void *buf) @@ -246,7 +246,7 @@
> > static bool hibernation_e820_mismatch(void *buf)
> >  	if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> >  		return false;
> >
> > -	ret = get_e820_md5(&e820_saved, result);
> > +	ret = get_e820_md5(e820_saved, result);
> >  	if (ret)
> >  		return true;
> >
> >
> 
> Looks good to me, thanks Stephen!
> 
> Rafael
Thanks for the fix!

I made a double check of the patch :
"x86/e820: Prepare e280 code for switch to dynamic storage"
It looks like this patch has reallocate the e820 & e820_save to their actual size:
+	size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820->nr_map;
+	n = kmalloc(size, GFP_KERNEL);

however the previous patch to verify the md5 hash during hibernation will
use the original e820_map structure by sizeof(struct e820map), which might 
read invalid value after the latest patch applied. I think I need to modify the 
hibernation e820 checking patch to only generate  md5 digest based on the actual 
e820_save size by sizeof(struct e820entry) * e820->nr_map.

I don't have a machine in hand now, will test later and give feedback later. Thanks again!
Yu

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-09-29  3:20 Stephen Rothwell
@ 2016-09-29 12:25 ` Rafael J. Wysocki
  2016-09-29 15:54   ` Chen, Yu C
  0 siblings, 1 reply; 245+ messages in thread
From: Rafael J. Wysocki @ 2016-09-29 12:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Denys Vlasenko, Chen Yu

On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   get_e820_md5(&e820_saved, buf);
>                ^
> arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
>  static int get_e820_md5(struct e820map *map, void *buf)
>             ^
> arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   ret = get_e820_md5(&e820_saved, result);
>                      ^
> arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
>  static int get_e820_md5(struct e820map *map, void *buf)
>             ^
> 
> Caused by commit
> 
>   475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic storage")
> 
> interacting with commit
> 
>   6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5 digest")
> 
> from the pm tree.
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Sep 2016 13:13:45 +1000
> Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved changing
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/power/hibernate_64.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
> index 72f2c9531b03..904048f7a9c9 100644
> --- a/arch/x86/power/hibernate_64.c
> +++ b/arch/x86/power/hibernate_64.c
> @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void *buf)
>  
>  static void hibernation_e820_save(void *buf)
>  {
> -	get_e820_md5(&e820_saved, buf);
> +	get_e820_md5(e820_saved, buf);
>  }
>  
>  static bool hibernation_e820_mismatch(void *buf)
> @@ -246,7 +246,7 @@ static bool hibernation_e820_mismatch(void *buf)
>  	if (!memcmp(result, buf, MD5_DIGEST_SIZE))
>  		return false;
>  
> -	ret = get_e820_md5(&e820_saved, result);
> +	ret = get_e820_md5(e820_saved, result);
>  	if (ret)
>  		return true;
>  
> 

Looks good to me, thanks Stephen!

Rafael

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-09-29  3:20 Stephen Rothwell
  2016-09-29 12:25 ` Rafael J. Wysocki
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2016-09-29  3:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Denys Vlasenko

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
  get_e820_md5(&e820_saved, buf);
               ^
arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
 static int get_e820_md5(struct e820map *map, void *buf)
            ^
arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
  ret = get_e820_md5(&e820_saved, result);
                     ^
arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
 static int get_e820_md5(struct e820map *map, void *buf)
            ^

Caused by commit

  475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic storage")

interacting with commit

  6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5 digest")

from the pm tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Sep 2016 13:13:45 +1000
Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved changing

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/power/hibernate_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 72f2c9531b03..904048f7a9c9 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void *buf)
 
 static void hibernation_e820_save(void *buf)
 {
-	get_e820_md5(&e820_saved, buf);
+	get_e820_md5(e820_saved, buf);
 }
 
 static bool hibernation_e820_mismatch(void *buf)
@@ -246,7 +246,7 @@ static bool hibernation_e820_mismatch(void *buf)
 	if (!memcmp(result, buf, MD5_DIGEST_SIZE))
 		return false;
 
-	ret = get_e820_md5(&e820_saved, result);
+	ret = get_e820_md5(e820_saved, result);
 	if (ret)
 		return true;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-09-21  3:23 Stephen Rothwell
@ 2016-09-21  6:44 ` Viresh Kumar
  0 siblings, 0 replies; 245+ messages in thread
From: Viresh Kumar @ 2016-09-21  6:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki, linux-next, linux-kernel,
	Sebastian Andrzej Siewior

On 21-09-16, 13:23, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/cpufreq/cpufreq.c:1324:12: error: conflicting types for 'cpufreq_offline'
>  static int cpufreq_offline(unsigned int cpu)
>             ^
> drivers/cpufreq/cpufreq.c:1289:13: note: previous declaration of 'cpufreq_offline' was here
>  static void cpufreq_offline(unsigned int cpu);
>              ^
> 
> Caused by commit
> 
>   27622b061eb4 ("cpufreq: Convert to hotplug state machine")
> 
> interacting with commit
> 
>   26619804e733 ("cpufreq: create link to policy only for registered CPUs")
> 
> from the pm tree.
> 
> I have applied the foloowing build fix for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 21 Sep 2016 13:20:32 +1000
> Subject: [PATCH] cpufreq: merge fix for type of cpufreq_offline changing
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/cpufreq/cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 611395cb115e..6e6c1fb60fbc 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1286,7 +1286,7 @@ out_free_policy:
>  	return ret;
>  }
>  
> -static void cpufreq_offline(unsigned int cpu);
> +static int cpufreq_offline(unsigned int cpu);

Thanks and sorry about it. Looks fine.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-09-21  3:23 Stephen Rothwell
  2016-09-21  6:44 ` Viresh Kumar
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2016-09-21  3:23 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Viresh Kumar, Sebastian Andrzej Siewior

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/cpufreq/cpufreq.c:1324:12: error: conflicting types for 'cpufreq_offline'
 static int cpufreq_offline(unsigned int cpu)
            ^
drivers/cpufreq/cpufreq.c:1289:13: note: previous declaration of 'cpufreq_offline' was here
 static void cpufreq_offline(unsigned int cpu);
             ^

Caused by commit

  27622b061eb4 ("cpufreq: Convert to hotplug state machine")

interacting with commit

  26619804e733 ("cpufreq: create link to policy only for registered CPUs")

from the pm tree.

I have applied the foloowing build fix for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Sep 2016 13:20:32 +1000
Subject: [PATCH] cpufreq: merge fix for type of cpufreq_offline changing

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/cpufreq/cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 611395cb115e..6e6c1fb60fbc 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1286,7 +1286,7 @@ out_free_policy:
 	return ret;
 }
 
-static void cpufreq_offline(unsigned int cpu);
+static int cpufreq_offline(unsigned int cpu);
 
 /**
  * cpufreq_add_dev - the cpufreq interface for a CPU device.
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-07-18  8:29 Stephen Rothwell
@ 2016-07-18 14:27 ` Paul Gortmaker
  0 siblings, 0 replies; 245+ messages in thread
From: Paul Gortmaker @ 2016-07-18 14:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

[linux-next: build failure after merge of the tip tree] On 18/07/2016 (Mon 18:29) Stephen Rothwell wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> In file included from arch/x86/kernel/x8664_ksyms_64.c:10:0:
> arch/x86/include/asm/pgtable.h:38:8: error: unknown type name 'spinlock_t'
>  extern spinlock_t pgd_lock;

>         ^
> 
> Probably caused by commit
> 
>   186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h")

Wondering why I didn't see this, when I _thought_ I did the same
coverage, I learned an interesting thing.  I'd been doing 

make ARCH=i386 allnoconfig
make allnoconfig

...figuring on x86_64 host that I'd need to explicitly choose i386 and
that w/o an ARCH specified, I'd get the native arch...  Not so.  I just
end up doing the i386 arch coverage twice.  :-(   I'll go out on a limb
here and guess I'm not the only person to fall into that trap.

I'll now be using:

make ARCH=i386 allnoconfig
make ARCH=x86_64 allnoconfig

Thanks Stephen for the fix and for helping find this gap in my tests.
If my build coverage moves to Power like yours, I'll still be good. :)

Paul.
--

> 
> I added this patch for today (maybe adding the include to
> arch/x86/include/asm/pgtable.h would be better?):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Jul 2016 18:23:24 +1000
> Subject: [PATCH] x86/kernel: include spinlock_types.h for missing spinlock_t
> 
> Fixes: 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/x8664_ksyms_64.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c
> index f6d30fedcc03..95e49f6e4fc3 100644
> --- a/arch/x86/kernel/x8664_ksyms_64.c
> +++ b/arch/x86/kernel/x8664_ksyms_64.c
> @@ -2,6 +2,7 @@
>     All C exports should go in the respective C files. */
>  
>  #include <linux/export.h>
> +#include <linux/spinlock_types.h>
>  #include <linux/smp.h>
>  
>  #include <net/checksum.h>
> -- 
> 2.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-07-18  8:29 Stephen Rothwell
  2016-07-18 14:27 ` Paul Gortmaker
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2016-07-18  8:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Paul Gortmaker

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

In file included from arch/x86/kernel/x8664_ksyms_64.c:10:0:
arch/x86/include/asm/pgtable.h:38:8: error: unknown type name 'spinlock_t'
 extern spinlock_t pgd_lock;
        ^

Probably caused by commit

  186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h")

I added this patch for today (maybe adding the include to
arch/x86/include/asm/pgtable.h would be better?):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Jul 2016 18:23:24 +1000
Subject: [PATCH] x86/kernel: include spinlock_types.h for missing spinlock_t

Fixes: 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/x8664_ksyms_64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c
index f6d30fedcc03..95e49f6e4fc3 100644
--- a/arch/x86/kernel/x8664_ksyms_64.c
+++ b/arch/x86/kernel/x8664_ksyms_64.c
@@ -2,6 +2,7 @@
    All C exports should go in the respective C files. */
 
 #include <linux/export.h>
+#include <linux/spinlock_types.h>
 #include <linux/smp.h>
 
 #include <net/checksum.h>
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-07-18  5:15 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-07-18  5:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo,
	Andy Lutomirski, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/string.h:5,
                 from ../lib/str_error_r.c:4:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
cat: /home/sfr/next/x86_64_allmodconfig/tools/objtool/.str_error_r.o.d: No such file or directory
Build:17: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/str_error_r.o' failed
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from special.h:22, 
                 from special.c:26: 
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/string.h:5,
                 from ../lib/string.c:18:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from elf.c:30:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from arch/x86/../../elf.h:23,
                 from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^
Makefile:42: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o' failed
Makefile:60: recipe for target 'objtool' failed

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Jul 2016 14:58:39 +1000
Subject: [PATCH] tools: Simplify __BITS_PER_LONG define

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/include/asm-generic/bitsperlong.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index 45eca517efb3..f46853474fd3 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -10,7 +10,8 @@
 #endif
 
 #if BITS_PER_LONG != __BITS_PER_LONG
-#error Inconsistent word size. Check asm/bitsperlong.h
+#undef __BITS_PER_LONG
+#define __BITS_PER_LONG	BITS_PER_LONG
 #endif
 
 #ifndef BITS_PER_LONG_LONG
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-18 13:24         ` Arnaldo Carvalho de Melo
@ 2016-04-18 13:28           ` Jiri Olsa
  0 siblings, 0 replies; 245+ messages in thread
From: Jiri Olsa @ 2016-04-18 13:28 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Mon, Apr 18, 2016 at 10:24:02AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, Apr 17, 2016 at 03:04:05PM +0200, Jiri Olsa escreveu:
> > On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote:
> > > On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > > > failed like this:
> > > > > > 
> > > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > > > > > 
> > > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > > > > > 
> > > > > > Presumably caused by commit
> > > > > > 
> > > > > >   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > > > > > 
> > > > > > I have reverted that commit for today (which fixes my build problem but
> > > > > > may not be overall correct).
> > > > > 
> > > > > Right, I'm trying to figure out how to bet fix that, one way would be to
> > > > > do:
> > > > 
> > > > Jiri, I think this is enough, i.e. I think we make sure, just like the
> > > > kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> > > > called before doing all the other build, no?
> > > > 
> > > > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> > > > built already, limited testing seems to agree with this :-)
> > > > 
> > > > - Arnaldo
> > > >  
> > > > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > > > > index 85a9ab62e23f..7fc4ac304ed6 100644
> > > > > --- a/tools/perf/util/Build
> > > > > +++ b/tools/perf/util/Build
> > > > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> > > > >  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> > > > >  CFLAGS_parse-events.o  += -Wno-redundant-decls
> > > > >  
> > > > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > > > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
> > > 
> > > yep, having arch specific target in generic Build file is wrong
> > > I'll have ppc64le available later today, I'll check on that
> > 
> > it looks ok, you can also now remove the whole syscalltbl.o override
> 
> Ok, so I'll add this and your Tested-by, ok?

ook ;-)

jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-17 13:04       ` Jiri Olsa
@ 2016-04-18 13:24         ` Arnaldo Carvalho de Melo
  2016-04-18 13:28           ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-04-18 13:24 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

Em Sun, Apr 17, 2016 at 03:04:05PM +0200, Jiri Olsa escreveu:
> On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote:
> > On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > > failed like this:
> > > > > 
> > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > > > > 
> > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > > > > 
> > > > > Presumably caused by commit
> > > > > 
> > > > >   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > > > > 
> > > > > I have reverted that commit for today (which fixes my build problem but
> > > > > may not be overall correct).
> > > > 
> > > > Right, I'm trying to figure out how to bet fix that, one way would be to
> > > > do:
> > > 
> > > Jiri, I think this is enough, i.e. I think we make sure, just like the
> > > kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> > > called before doing all the other build, no?
> > > 
> > > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> > > built already, limited testing seems to agree with this :-)
> > > 
> > > - Arnaldo
> > >  
> > > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > > > index 85a9ab62e23f..7fc4ac304ed6 100644
> > > > --- a/tools/perf/util/Build
> > > > +++ b/tools/perf/util/Build
> > > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> > > >  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> > > >  CFLAGS_parse-events.o  += -Wno-redundant-decls
> > > >  
> > > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
> > 
> > yep, having arch specific target in generic Build file is wrong
> > I'll have ppc64le available later today, I'll check on that
> 
> it looks ok, you can also now remove the whole syscalltbl.o override

Ok, so I'll add this and your Tested-by, ok?

- Arnaldo
 
> and archheaders needs to be called before the build starts,
> which is the case right now
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index 85a9ab62e23f..90229a88f969 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -150,10 +150,6 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
>  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
>  CFLAGS_parse-events.o  += -Wno-redundant-decls
>  
> -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> -	$(call rule_mkdir)
> -	$(call if_changed_dep,cc_o_c)
> -
>  $(OUTPUT)util/kallsyms.o: ../lib/symbol/kallsyms.c FORCE
>  	$(call rule_mkdir)
>  	$(call if_changed_dep,cc_o_c)

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-04-18  3:03 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-04-18  3:03 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
failed like this:

builtin-trace.c: In function 'cmd_trace':
builtin-trace.c:3112:7: error: variable 'max_stack_user_set' set but not used [-Werror=unused-but-set-variable]
  bool max_stack_user_set = true;
       ^

Caused by commit

  056149932602 ("perf trace: Make --(min,max}-stack imply "--call-graph dwarf"")

I added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Apr 2016 12:56:48 +1000
Subject: [PATCH] perf: trace: fix build when HAVE_DWARF_UNWIND_SUPPORT is not set

Fixes: 056149932602 ("perf trace: Make --(min,max}-stack imply "--call-graph dwarf"")

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/perf/builtin-trace.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 026ec0c749b0..48dc23a4f405 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -3109,7 +3109,9 @@ int cmd_trace(int argc, const char **argv, const char *prefix __maybe_unused)
 			"per thread proc mmap processing timeout in ms"),
 	OPT_END()
 	};
+#ifdef HAVE_DWARF_UNWIND_SUPPORT
 	bool max_stack_user_set = true;
+#endif
 	bool mmap_pages_user_set = true;
 	const char * const trace_subcommands[] = { "record", NULL };
 	int err;
@@ -3149,7 +3151,9 @@ int cmd_trace(int argc, const char **argv, const char *prefix __maybe_unused)
 
 	if (trace.max_stack == UINT_MAX) {
 		trace.max_stack = PERF_MAX_STACK_DEPTH;
+#ifdef HAVE_DWARF_UNWIND_SUPPORT
 		max_stack_user_set = false;
+#endif
 	}
 
 #ifdef HAVE_DWARF_UNWIND_SUPPORT
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-17 12:12     ` Jiri Olsa
@ 2016-04-17 13:04       ` Jiri Olsa
  2016-04-18 13:24         ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 245+ messages in thread
From: Jiri Olsa @ 2016-04-17 13:04 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote:
> On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > failed like this:
> > > > 
> > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > > > 
> > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > > > 
> > > > Presumably caused by commit
> > > > 
> > > >   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > > > 
> > > > I have reverted that commit for today (which fixes my build problem but
> > > > may not be overall correct).
> > > 
> > > Right, I'm trying to figure out how to bet fix that, one way would be to
> > > do:
> > 
> > Jiri, I think this is enough, i.e. I think we make sure, just like the
> > kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> > called before doing all the other build, no?
> > 
> > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> > built already, limited testing seems to agree with this :-)
> > 
> > - Arnaldo
> >  
> > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > > index 85a9ab62e23f..7fc4ac304ed6 100644
> > > --- a/tools/perf/util/Build
> > > +++ b/tools/perf/util/Build
> > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> > >  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> > >  CFLAGS_parse-events.o  += -Wno-redundant-decls
> > >  
> > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
> 
> yep, having arch specific target in generic Build file is wrong
> I'll have ppc64le available later today, I'll check on that

it looks ok, you can also now remove the whole syscalltbl.o override

and archheaders needs to be called before the build starts,
which is the case right now

thanks,
jirka


---
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 85a9ab62e23f..90229a88f969 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -150,10 +150,6 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
 CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
 CFLAGS_parse-events.o  += -Wno-redundant-decls
 
-$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
-	$(call rule_mkdir)
-	$(call if_changed_dep,cc_o_c)
-
 $(OUTPUT)util/kallsyms.o: ../lib/symbol/kallsyms.c FORCE
 	$(call rule_mkdir)
 	$(call if_changed_dep,cc_o_c)

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-15 21:28   ` Arnaldo Carvalho de Melo
@ 2016-04-17 12:12     ` Jiri Olsa
  2016-04-17 13:04       ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Jiri Olsa @ 2016-04-17 12:12 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > failed like this:
> > > 
> > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > > 
> > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > > 
> > > Presumably caused by commit
> > > 
> > >   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > > 
> > > I have reverted that commit for today (which fixes my build problem but
> > > may not be overall correct).
> > 
> > Right, I'm trying to figure out how to bet fix that, one way would be to
> > do:
> 
> Jiri, I think this is enough, i.e. I think we make sure, just like the
> kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> called before doing all the other build, no?
> 
> I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> built already, limited testing seems to agree with this :-)
> 
> - Arnaldo
>  
> > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > index 85a9ab62e23f..7fc4ac304ed6 100644
> > --- a/tools/perf/util/Build
> > +++ b/tools/perf/util/Build
> > @@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> >  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> >  CFLAGS_parse-events.o  += -Wno-redundant-decls
> >  
> > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE

yep, having arch specific target in generic Build file is wrong
I'll have ppc64le available later today, I'll check on that

jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-15 21:15 ` Arnaldo Carvalho de Melo
@ 2016-04-15 21:28   ` Arnaldo Carvalho de Melo
  2016-04-17 12:12     ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-04-15 21:28 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Jiri Olsa, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > failed like this:
> > 
> > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > 
> > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > 
> > Presumably caused by commit
> > 
> >   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > 
> > I have reverted that commit for today (which fixes my build problem but
> > may not be overall correct).
> 
> Right, I'm trying to figure out how to bet fix that, one way would be to
> do:

Jiri, I think this is enough, i.e. I think we make sure, just like the
kernel, that the archheaders target in tools/perf/arch/*/Makefile is
called before doing all the other build, no?

I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
built already, limited testing seems to agree with this :-)

- Arnaldo
 
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index 85a9ab62e23f..7fc4ac304ed6 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
>  CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
>  CFLAGS_parse-events.o  += -Wno-redundant-decls
>  
> -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
>  	$(call rule_mkdir)
>  	$(call if_changed_dep,cc_o_c)
>  
> 
> --------------------------------------------
> 
> Now trying to figure out how to, just for x86 to add a dep for those
> files, but a arch specific thing shouldn't be in tools/perf/util/Build
> anyway...
> 
> In the end I want this syscalltbl.c thing to know about all arches,
> to remove the dependency on audit-libs as the way to map syscall ID to
> name and vice-versa.
> 
> So I'll need all arches to generate that
> arch/$(ARCH)/include/generated/asm/syscalls_64.c file, etc. Doing that
> by copying from the kernel the files where such info is kept and having
> a diff check as part of the perf build process, so that we can get
> notified when it drifts while not tying tools/perf/  to anything outside
> that can end up breaking the tools/ build when changes happen outside.
> 
> - Arnaldo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-14  2:14 Stephen Rothwell
  2016-04-14 12:35 ` Arnaldo Carvalho de Melo
@ 2016-04-15 21:15 ` Arnaldo Carvalho de Melo
  2016-04-15 21:28   ` Arnaldo Carvalho de Melo
  1 sibling, 1 reply; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-04-15 21:15 UTC (permalink / raw)
  To: Jiri Olsa, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, acme

Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> failed like this:
> 
> make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> 
> (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> 
> Presumably caused by commit
> 
>   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> 
> I have reverted that commit for today (which fixes my build problem but
> may not be overall correct).

Right, I'm trying to figure out how to bet fix that, one way would be to
do:

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 85a9ab62e23f..7fc4ac304ed6 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -150,7 +150,7 @@ CFLAGS_libstring.o     += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
 CFLAGS_hweight.o       += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
 CFLAGS_parse-events.o  += -Wno-redundant-decls
 
-$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
+$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
 	$(call rule_mkdir)
 	$(call if_changed_dep,cc_o_c)
 

--------------------------------------------

Now trying to figure out how to, just for x86 to add a dep for those
files, but a arch specific thing shouldn't be in tools/perf/util/Build
anyway...

In the end I want this syscalltbl.c thing to know about all arches,
to remove the dependency on audit-libs as the way to map syscall ID to
name and vice-versa.

So I'll need all arches to generate that
arch/$(ARCH)/include/generated/asm/syscalls_64.c file, etc. Doing that
by copying from the kernel the files where such info is kept and having
a diff check as part of the perf build process, so that we can get
notified when it drifts while not tying tools/perf/  to anything outside
that can end up breaking the tools/ build when changes happen outside.

- Arnaldo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-14 12:55   ` Michael Ellerman
@ 2016-04-14 15:08     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-04-14 15:08 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

Em Thu, Apr 14, 2016 at 10:55:47PM +1000, Michael Ellerman escreveu:
> On Thu, 2016-04-14 at 09:35 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > failed like this:
> > > 
> > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > > 
> > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > 
> > I'll check, should've been caught by a cross compiler build for ppc64le
> > I have in place :-\
> > 
> > minimal-ubuntu-x-ppc64el: Ok
> > 
> > But maybe not, as this requires audit-libs-devel and that is not present
> > on that minimal ubuntu x-compiler setup, sigh :-\
> 
> Hi acme,
> 
> I have a jenkins which builds perf on ppc64le, but it only builds Linus' tree
> and linux-next.
> 
> Which branch in your tree should I be building in order to catch problems like
> this, perf/core ?
> 
> https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/core

yes, please, I use two normally, one for devel stuff, perf/core, and
perf/urgent when sending stuff to the current merge window.

I'll continue trying to get a local, more complete, cross compiler
environment, need to look again at how that multiarch stuff is in
debian...

- Arnaldo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-14 12:35 ` Arnaldo Carvalho de Melo
@ 2016-04-14 12:55   ` Michael Ellerman
  2016-04-14 15:08     ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 245+ messages in thread
From: Michael Ellerman @ 2016-04-14 12:55 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Thu, 2016-04-14 at 09:35 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > failed like this:
> > 
> > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> > 
> > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> 
> I'll check, should've been caught by a cross compiler build for ppc64le
> I have in place :-\
> 
> minimal-ubuntu-x-ppc64el: Ok
> 
> But maybe not, as this requires audit-libs-devel and that is not present
> on that minimal ubuntu x-compiler setup, sigh :-\

Hi acme,

I have a jenkins which builds perf on ppc64le, but it only builds Linus' tree
and linux-next.

Which branch in your tree should I be building in order to catch problems like
this, perf/core ?

https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/core

cheers

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-04-14  2:14 Stephen Rothwell
@ 2016-04-14 12:35 ` Arnaldo Carvalho de Melo
  2016-04-14 12:55   ` Michael Ellerman
  2016-04-15 21:15 ` Arnaldo Carvalho de Melo
  1 sibling, 1 reply; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-04-14 12:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> failed like this:
> 
> make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.
> 
> (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)

I'll check, should've been caught by a cross compiler build for ppc64le
I have in place :-\

minimal-ubuntu-x-ppc64el: Ok

But maybe not, as this requires audit-libs-devel and that is not present
on that minimal ubuntu x-compiler setup, sigh :-\

- Arnaldo
 
> Presumably caused by commit
> 
>   1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> 
> I have reverted that commit for today (which fixes my build problem but
> may not be overall correct).
> 
> -- 
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-04-14  2:14 Stephen Rothwell
  2016-04-14 12:35 ` Arnaldo Carvalho de Melo
  2016-04-15 21:15 ` Arnaldo Carvalho de Melo
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-04-14  2:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
failed like this:

make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'.  Stop.

(I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)

Presumably caused by commit

  1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")

I have reverted that commit for today (which fixes my build problem but
may not be overall correct).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  8:41       ` Sedat Dilek
@ 2016-03-01  9:45       ` Ingo Molnar
  1 sibling, 0 replies; 245+ messages in thread
From: Ingo Molnar @ 2016-03-01  9:45 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: sedat.dilek, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf


* H. Peter Anvin <hpa@zytor.com> wrote:

> That is not the issue here.  The problem is clearly that objtool is a host 
> program and not compiled with host cc.  So it is a good thing to test even 
> though it is weird, because it affects real use cases.

Absolutely, it's a real bug that should be fixed. What is counterproductive is 
that this rare and hard to replicate build modus is now a must-have test for 
linux-next inclusion.

I already cross-build to 20+ weird, rarely used architectures, slowing down the 
linux-next merge integration test immensely and wasting quite a bit of 
electricity. linux-next making it even harder to test for is a step backwards.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:07 ` Ingo Molnar
  2016-03-01  7:28   ` Sedat Dilek
@ 2016-03-01  9:40   ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2016-03-01  9:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Josh Poimboeuf

Hi Ingo,

On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> > This build is done with a PowerPC hosted cross compiler with no glibc.  
> 
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
> dependent on it?

It is just the fastest hardware I currently have access to (you remember
who I work for, right? ;-)).  I have always done at least part of the
linux-next building (daily, or overnight) on PowerPC hardware and this
is only the 2nd or third time in over 8 years that it has found an
issue like this.

> > I assume that some things here need to be built with HOSTCC?  
> 
> I suspect that's the culprit.

Good, hopefully it is not too hard to fix.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:39     ` H. Peter Anvin
@ 2016-03-01  8:41       ` Sedat Dilek
  2016-03-01  9:45       ` Ingo Molnar
  1 sibling, 0 replies; 245+ messages in thread
From: Sedat Dilek @ 2016-03-01  8:41 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf

On Tue, Mar 1, 2016 at 8:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After merging the tip tree, today's linux-next build (x86_64
>>allmodconfig)
>>>> failed like this:
>>>>
>>>>   DESCEND  objtool
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>>   MKDIR
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>>> compilation terminated.
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>>directory
>>>> compilation terminated.
>>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>>> compilation terminated.
>>>>
>>>> and further errors ...
>>>>
>>>> This build is done with a PowerPC hosted cross compiler with no
>>glibc.
>>>
>>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>>linux-next
>>> dependent on it?
>>>
>>>> I assume that some things here need to be built with HOSTCC?
>>>
>>> I suspect that's the culprit. Do you now mandate people to have
>>PowerPC systems as
>>> a requirement to merge to linux-next? How are people supposed to be
>>able to test
>>> that rare type of build method which does not matter to 99.99% of our
>>kernel
>>> testers and users?
>>>
>>
> >From my experience in using different $COMPILER you should always pass
>>CC and HOSTCC in your make-line when building a Linux-kernel or
>>playing with the Kconfig-system.
>>
>>When building my llvm-toolchain with make/autoconf I had also to pass
>>CC and CXX to my configure-line otherwise you got misconfiguration.
>>
>>[ EXAMPLE: Linux Kconfig-system ]
>>
>>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>>HOSTCC=$COMPILER"
>>
>>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>>silentoldconfig < /dev/null
>>
>>- Sedat -
>
> That is not the issue here.  The problem is clearly that objtool is a host program and not compiled with host cc.  So it is a good thing to test even though it is weird, because it affects real use cases.
>
> As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
>

Thanks for the clarification.

I talked about my experiences in software building in general.

When this is a "tools/objtool problem" then someone should address
this to "tools/objtool maintainers/folks" or whoever else is
responsible.

- Sedat -

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:28   ` Sedat Dilek
@ 2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  8:41       ` Sedat Dilek
  2016-03-01  9:45       ` Ingo Molnar
  0 siblings, 2 replies; 245+ messages in thread
From: H. Peter Anvin @ 2016-03-01  7:39 UTC (permalink / raw)
  To: sedat.dilek, Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, LKML, Josh Poimboeuf

On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>>   DESCEND  objtool
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>   MKDIR   
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -

That is not the issue here.  The problem is clearly that objtool is a host program and not compiled with host cc.  So it is a good thing to test even though it is weird, because it affects real use cases.

As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:07 ` Ingo Molnar
@ 2016-03-01  7:28   ` Sedat Dilek
  2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  9:40   ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Sedat Dilek @ 2016-03-01  7:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf

On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>>   DESCEND  objtool
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>   MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>> compilation terminated.
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>> builtin-check.c:28:20: fatal error: string.h: No such file or directory
>> compilation terminated.
>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>> compilation terminated.
>>
>> and further errors ...
>>
>> This build is done with a PowerPC hosted cross compiler with no glibc.
>
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next
> dependent on it?
>
>> I assume that some things here need to be built with HOSTCC?
>
> I suspect that's the culprit. Do you now mandate people to have PowerPC systems as
> a requirement to merge to linux-next? How are people supposed to be able to test
> that rare type of build method which does not matter to 99.99% of our kernel
> testers and users?
>

>From my experience in using different $COMPILER you should always pass
CC and HOSTCC in your make-line when building a Linux-kernel or
playing with the Kconfig-system.

When building my llvm-toolchain with make/autoconf I had also to pass
CC and CXX to my configure-line otherwise you got misconfiguration.

[ EXAMPLE: Linux Kconfig-system ]

$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
HOSTCC=$COMPILER"

$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
silentoldconfig < /dev/null

- Sedat -

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  1:29 Stephen Rothwell
@ 2016-03-01  7:07 ` Ingo Molnar
  2016-03-01  7:28   ` Sedat Dilek
  2016-03-01  9:40   ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Ingo Molnar @ 2016-03-01  7:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Josh Poimboeuf


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
>   DESCEND  objtool
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>   MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
> elf.c:22:23: fatal error: sys/types.h: No such file or directory
> compilation terminated.
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
> builtin-check.c:28:20: fatal error: string.h: No such file or directory
> compilation terminated.
> objtool.c:28:19: fatal error: stdio.h: No such file or directory
> compilation terminated.
> 
> and further errors ...
> 
> This build is done with a PowerPC hosted cross compiler with no glibc.

Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
dependent on it?

> I assume that some things here need to be built with HOSTCC?

I suspect that's the culprit. Do you now mandate people to have PowerPC systems as 
a requirement to merge to linux-next? How are people supposed to be able to test 
that rare type of build method which does not matter to 99.99% of our kernel 
testers and users?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2016-03-01  1:29 Stephen Rothwell
  2016-03-01  7:07 ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2016-03-01  1:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Josh Poimboeuf

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

  DESCEND  objtool
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
  MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
elf.c:22:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
builtin-check.c:28:20: fatal error: string.h: No such file or directory
compilation terminated.
objtool.c:28:19: fatal error: stdio.h: No such file or directory
compilation terminated.

and further errors ...

This build is done with a PowerPC hosted cross compiler with no glibc.
I assume that some things here need to be built with HOSTCC?

Presumably caused by commit

  9e54249679b4 ("Merge branch 'core/objtool'")

and the commit series that was merged.

I tried to revert that merge, but it had conflicts, so I just used the
tip tree from next-20160229 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-30  6:08       ` Jiri Olsa
@ 2015-09-30  6:17         ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-30  6:17 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 30 Sep 2015 08:08:12 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> ouch, forgot to CC you, sry

No worries, I was watching ...

> it won't fix the build if you still have old .cmd file in you tree (I presume that's the case),
> once those are regenerated you shouldn't meet the issue again

Unfortunately this is what happens to me every day :-( (at least until
these changes are merged into Linus' tree).  Its fine, I have automated
the clean up of the perf build object directory after merging the tip
tree.  However, this will also happen to anyone who has built perf then
updates their tree and then tries to rebuild perf.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-30  2:56     ` Stephen Rothwell
@ 2015-09-30  6:08       ` Jiri Olsa
  2015-09-30  6:17         ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Jiri Olsa @ 2015-09-30  6:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 30, 2015 at 12:56:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > > 
> > > > After merging the tip tree, today's linux-next build (perf) failed
> > > > like this:
> > > > 
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > > Makefile:68: recipe for target 'all' failed
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > > > 
> > > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > > the build for each tree merge (in case that matters).
> > > 
> > > it does in this case, removed header files stay in
> > > cmd build dependency file (like in .abspath.o.cmd above)
> > > and cause build error
> > > 
> > > build system is not smart enough yet to find out,
> > > I was postponning fixing this for some time now,
> > > I'll try to get this resolved asap
> > 
> > OK, for now I will clean out my objdir before doing the perf build
> > after the tip tree merge.  It would be nice to have this fixed, though,
> > if possible.
> 
> I noticed some commits in the tip tree today that seemed as though they
> were addressing this problem.  However, I still get a build failure if
> I don't clean out the object directory before building tools/perf:

ouch, forgot to CC you, sry

> 
>   BUILD:   Doing 'make -j48' parallel build
>   GEN      /home/sfr/next/perf/common-cmds.h
>   CC       /home/sfr/next/perf/fixdep.o
>   LD       /home/sfr/next/perf/fixdep-in.o
>   LINK     /home/sfr/next/perf/fixdep
>   CC       /home/sfr/next/perf/perf-read-vdso32
>   CC       /home/sfr/next/perf/perf-read-vdsox32
> make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
> /home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed
> make[2]: *** [ui/gtk] Error 2
> Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

it won't fix the build if you still have old .cmd file in you tree (I presume that's the case),
once those are regenerated you shouldn't meet the issue again

jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-17  0:34   ` Stephen Rothwell
@ 2015-09-30  2:56     ` Stephen Rothwell
  2015-09-30  6:08       ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-30  2:56 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi all,

On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (perf) failed
> > > like this:
> > > 
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > Makefile:68: recipe for target 'all' failed
> > > 
> > > Maybe caused by commit
> > > 
> > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > > 
> > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > the build for each tree merge (in case that matters).
> > 
> > it does in this case, removed header files stay in
> > cmd build dependency file (like in .abspath.o.cmd above)
> > and cause build error
> > 
> > build system is not smart enough yet to find out,
> > I was postponning fixing this for some time now,
> > I'll try to get this resolved asap
> 
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge.  It would be nice to have this fixed, though,
> if possible.

I noticed some commits in the tip tree today that seemed as though they
were addressing this problem.  However, I still get a build failure if
I don't clean out the object directory before building tools/perf:

  BUILD:   Doing 'make -j48' parallel build
  GEN      /home/sfr/next/perf/common-cmds.h
  CC       /home/sfr/next/perf/fixdep.o
  LD       /home/sfr/next/perf/fixdep-in.o
  LINK     /home/sfr/next/perf/fixdep
  CC       /home/sfr/next/perf/perf-read-vdso32
  CC       /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

(/home/sfr/next/perf/ is the object directory)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:16 ` Jiri Olsa
  2015-09-16  6:38   ` Jiri Olsa
@ 2015-09-17  0:34   ` Stephen Rothwell
  2015-09-30  2:56     ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-17  0:34 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap

OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge.  It would be nice to have this fixed, though,
if possible.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  7:30     ` Stephen Rothwell
@ 2015-09-16 14:17       ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 245+ messages in thread
From: Arnaldo Carvalho de Melo @ 2015-09-16 14:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jiri Olsa, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Jiri Olsa

Em Wed, Sep 16, 2015 at 05:30:25PM +1000, Stephen Rothwell escreveu:
> Hi Jiri,
> 
> On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > > > Also, building perf seems to ignore O=<dir> on the make invocation.
> > > > Is that expected?
> > > 
> > > hum, not sure about this one.. I'm not using it, but we have
> > > tests for this and I thought we're ok.. I'll check
> > 
> > seems to work on latest Arnaldo's perf/core,
> > what command line failed for you?
> > 
> > [jolsa@krava perf]$ make O=/tmp/krava/
> > ...
> > [jolsa@krava perf]$ ll /tmp/krava/perf
> > -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
> 
> Thanks for the hint.  I was using a relative path and starting in the
> top of the kernel tree, so:

> $ cd kernel
> $ mkdir ../perf
> $ make -s -C tools/perf JOBS=24 O=../perf
> 
> put everything in toos/perf (no suprise really)
> 
> I will change my script to use an absolute path (which I checked does
> work fine).  Sorry for the noise.

Nice workaround, but I guess relative paths should be supported as well,
right? :)

- Arnaldo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:38   ` Jiri Olsa
@ 2015-09-16  7:30     ` Stephen Rothwell
  2015-09-16 14:17       ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-16  7:30 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> > > Also, building perf seems to ignore O=<dir> on the make invocation.
> > > Is that expected?
> > 
> > hum, not sure about this one.. I'm not using it, but we have
> > tests for this and I thought we're ok.. I'll check
> 
> seems to work on latest Arnaldo's perf/core,
> what command line failed for you?
> 
> [jolsa@krava perf]$ make O=/tmp/krava/
> ...
> [jolsa@krava perf]$ ll /tmp/krava/perf
> -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf

Thanks for the hint.  I was using a relative path and starting in the
top of the kernel tree, so:

$ cd kernel
$ mkdir ../perf
$ make -s -C tools/perf JOBS=24 O=../perf

put everything in toos/perf (no suprise really)

I will change my script to use an absolute path (which I checked does
work fine).  Sorry for the noise.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:16 ` Jiri Olsa
@ 2015-09-16  6:38   ` Jiri Olsa
  2015-09-16  7:30     ` Stephen Rothwell
  2015-09-17  0:34   ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Jiri Olsa @ 2015-09-16  6:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
> 
> > 
> > I have used the tip tree from next-20150915 for today.
> > 
> > Also, building perf seems to ignore O=<dir> on the make invocation.
> > Is that expected?
> 
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check

seems to work on latest Arnaldo's perf/core,
what command line failed for you?

[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf


jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  0:12 Stephen Rothwell
@ 2015-09-16  6:16 ` Jiri Olsa
  2015-09-16  6:38   ` Jiri Olsa
  2015-09-17  0:34   ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Jiri Olsa @ 2015-09-16  6:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'arch' failed
> make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'fs' failed
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'util' failed
> Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> Makefile:68: recipe for target 'all' failed
> 
> Maybe caused by commit
> 
>   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> 
> This is an incremental build i.e. I do not do a "make clean" after doing
> the build for each tree merge (in case that matters).

it does in this case, removed header files stay in
cmd build dependency file (like in .abspath.o.cmd above)
and cause build error

build system is not smart enough yet to find out,
I was postponning fixing this for some time now,
I'll try to get this resolved asap

> 
> I have used the tip tree from next-20150915 for today.
> 
> Also, building perf seems to ignore O=<dir> on the make invocation.
> Is that expected?

hum, not sure about this one.. I'm not using it, but we have
tests for this and I thought we're ok.. I'll check

jirka

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  1:30 Stephen Rothwell
@ 2015-09-16  4:53 ` David Miller
  0 siblings, 0 replies; 245+ messages in thread
From: David Miller @ 2015-09-16  4:53 UTC (permalink / raw)
  To: sfr; +Cc: tglx, mingo, hpa, peterz, netdev, linux-next, linux-kernel, oneukum

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks Stephen.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-09-16  1:30 Stephen Rothwell
  2015-09-16  4:53 ` David Miller
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-16  1:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, netdev
  Cc: linux-next, linux-kernel, Oliver Neukum

Hi all,

After merging the next-20150915 version of the tip tree, today's
linux-next build (x86_64 allmodconfig) failed like this:

In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
                 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
                 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^

Caused by commit

  c40a2c8817e4 ("CDC: common parser for extra headers")

from the net-next tree that added include/linux/usb/cdc.h with no
reinclusion guards.

I am not sure why I did not see this failure when building after
merging the net-next tree.  Maybe it is exposed by some config change
in the tip tree?

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Sep 2015 11:10:16 +1000
Subject: [PATCH] cdc: add header guards

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/usb/cdc.h      | 4 ++++
 include/uapi/linux/usb/cdc.h | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 959d0c838113..b5706f94ee9e 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -7,6 +7,8 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  */
+#ifndef __LINUX_USB_CDC_H
+#define __LINUX_USB_CDC_H
 
 #include <uapi/linux/usb/cdc.h>
 
@@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 				struct usb_interface *intf,
 				u8 *buffer,
 				int buflen);
+
+#endif /* __LINUX_USB_CDC_H */
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index b6a9cdd6e096..e2bc417b243b 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -6,8 +6,8 @@
  * firmware based USB peripherals.
  */
 
-#ifndef __LINUX_USB_CDC_H
-#define __LINUX_USB_CDC_H
+#ifndef __UAPI_LINUX_USB_CDC_H
+#define __UAPI_LINUX_USB_CDC_H
 
 #include <linux/types.h>
 
@@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size {
 #define USB_CDC_NCM_CRC_NOT_APPENDED			0x00
 #define USB_CDC_NCM_CRC_APPENDED			0x01
 
-#endif /* __LINUX_USB_CDC_H */
+#endif /* __UAPI_LINUX_USB_CDC_H */
-- 
2.5.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-09-16  0:12 Stephen Rothwell
  2015-09-16  6:16 ` Jiri Olsa
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-09-16  0:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (perf) failed
like this:

make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'arch' failed
make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'fs' failed
make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'util' failed
Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
Makefile:68: recipe for target 'all' failed

Maybe caused by commit

  60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")

This is an incremental build i.e. I do not do a "make clean" after doing
the build for each tree merge (in case that matters).

I have used the tip tree from next-20150915 for today.

Also, building perf seems to ignore O=<dir> on the make invocation.
Is that expected?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28 16:34 ` Luis R. Rodriguez
@ 2015-07-28 18:17   ` Luis R. Rodriguez
  0 siblings, 0 replies; 245+ messages in thread
From: Luis R. Rodriguez @ 2015-07-28 18:17 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, benh
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Tue, Jul 28, 2015 at 06:34:19PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> > drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >   ^
> > drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >                    ^
> > 
> > Caused by commits
> > 
> >   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
> >   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> > 
> > The latter defines ioremap_uc() for x86 and those architectures that
> > use asm-generic/io.h - which is not all of them :-( .  The former commit
> > then uses ioremap_uc().
> > 
> > I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> > for today.
> 
> This should be fixed by:
> 
> http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb
> 
> The way it was defined was to return NULL if an arch does not have it,
> *but* if the asm-generic io.h header is not included on some archs it will still
> fail, which leaves us no option but to then poke and define its implementaiton
> for archs which opt-out of asm-generic io.h
> 
> Benh, in this case I believe its OK to to just map it to ioremap(), let me know
> what you think.
> 

I checked and there are other architectures that do not include asm-generic/io.h,
so here is the full patch fix, which I'll post next.

From: "Luis R. Rodriguez" <mcgrof@suse.com>
Subject: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures

This adds ioremap_uc() only for architectures that do not
include asm-generic.h/io.h as that already provides a default
definition for them for both cases where you have CONFIG_MMU
and you do not, and because of this, the number of architectures
this patch address is less than the architectures that the
ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to all
architectures").

In order to reduce the number of architectures we have to
modify by adding new architecture IO APIs we'll have to review
the architectures in this patch, see why they can't add
asm-generic.h/io.h or issues that would be created by doing
so and then spread a consistent inclusion of this header
towards the end of their own header. For instance arch/metag
includes the asm-generic/io.h *before* the ioremap*()
definitions, this should be the other way around but only
once we have guard wrappers for the non-MMU case also for
asm-generic/io.h.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/avr32/include/asm/io.h   | 1 +
 arch/frv/include/asm/io.h     | 1 +
 arch/m32r/include/asm/io.h    | 1 +
 arch/m68k/include/asm/io_mm.h | 1 +
 arch/mn10300/include/asm/io.h | 1 +
 arch/powerpc/include/asm/io.h | 1 +
 arch/sh/include/asm/io.h      | 1 +
 arch/tile/include/asm/io.h    | 1 +
 8 files changed, 8 insertions(+)

diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index e998ff5d8e1a..f855646e0db7 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -297,6 +297,7 @@ extern void __iounmap(void __iomem *addr);
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index a31b63ec4930..70dfbea8c8d7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -278,6 +278,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned l
 }
 
 #define ioremap_wc ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 extern void iounmap(void volatile __iomem *addr);
 
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index f8de767ce2bc..61b8931bc192 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -69,6 +69,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index f55cad529400..c98ac81582ac 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -468,6 +468,7 @@ static inline void __iomem *ioremap_nocache(unsigned long physaddr, unsigned lon
 {
 	return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
+#define ioremap_uc ioremap_nocache
 static inline void __iomem *ioremap_wt(unsigned long physaddr,
 					 unsigned long size)
 {
diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index 07c5b4a3903b..62189353d2f6 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -283,6 +283,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 static inline void iounmap(void __iomem *addr)
 {
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..5879fde56f3c 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
 				  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)	ioremap((addr), (size))
+#define ioremap_uc(addr, size)		ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 728c4c571f40..93ec9066dbef 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -368,6 +368,7 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; }
 #endif
 
 #define ioremap_nocache	ioremap
+#define ioremap_uc	ioremap
 #define iounmap		__iounmap
 
 /*
diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index dc61de15c1f9..322b5fe94781 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -55,6 +55,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_wc(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_wt(physaddr, size)		ioremap(physaddr, size)
+#define ioremap_uc(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_fullcache(physaddr, size)	ioremap(physaddr, size)
 
 #define mmiowb()
-- 
2.3.2.209.gd67f9d5.dirty

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  5:33 Stephen Rothwell
@ 2015-07-28 16:34 ` Luis R. Rodriguez
  2015-07-28 18:17   ` Luis R. Rodriguez
  0 siblings, 1 reply; 245+ messages in thread
From: Luis R. Rodriguez @ 2015-07-28 16:34 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, benh
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>   ^
> drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>                    ^
> 
> Caused by commits
> 
>   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
>   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> 
> The latter defines ioremap_uc() for x86 and those architectures that
> use asm-generic/io.h - which is not all of them :-( .  The former commit
> then uses ioremap_uc().
> 
> I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> for today.

This should be fixed by:

http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb

The way it was defined was to return NULL if an arch does not have it,
*but* if the asm-generic io.h header is not included on some archs it will still
fail, which leaves us no option but to then poke and define its implementaiton
for archs which opt-out of asm-generic io.h

Benh, in this case I believe its OK to to just map it to ioremap(), let me know
what you think.

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..91db9153cd44 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
 				  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)	ioremap((addr), (size))
+#define ioremap_uc(addr, size)	ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 

  Luis

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  8:41 ` Sudeep Holla
@ 2015-07-28  9:43   ` Gregory CLEMENT
  0 siblings, 0 replies; 245+ messages in thread
From: Gregory CLEMENT @ 2015-07-28  9:43 UTC (permalink / raw)
  To: Sudeep Holla, Stephen Rothwell
  Cc: linux-arm-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Jason Cooper, andrew, linux-next, linux-kernel,
	Thomas Petazzoni

Hi Sudeep, Stephen,

On 28/07/2015 10:41, Sudeep Holla wrote:
> Hi Stephen,
> 
> On 28/07/15 03:43, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
>> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
>>     gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
>>     ^
>>
>> Caused by commit
>>
>>    e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")
>>
>> from the mvebu tree interacting with commit
>>
>>    0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
>>
>> from the tip tree.
>>
>> I have applied the following merge fix patch for today:
>>
> 
> Thanks for the fix, I was aware of this and asked Thomas Petazzoni
> and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
> yesterday [1]
> 

I've just remove the commit from my branches, it should be OK now.


Thanks,

Gregory


> Regards,
> Sudeep
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  2:43 Stephen Rothwell
@ 2015-07-28  8:41 ` Sudeep Holla
  2015-07-28  9:43   ` Gregory CLEMENT
  0 siblings, 1 reply; 245+ messages in thread
From: Sudeep Holla @ 2015-07-28  8:41 UTC (permalink / raw)
  To: Stephen Rothwell, gregory.clement, linux-arm-kernel
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Jason Cooper, andrew, Sudeep Holla, linux-next, linux-kernel,
	Thomas Petazzoni

Hi Stephen,

On 28/07/15 03:43, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
>     gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
>     ^
>
> Caused by commit
>
>    e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")
>
> from the mvebu tree interacting with commit
>
>    0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
>
> from the tip tree.
>
> I have applied the following merge fix patch for today:
>

Thanks for the fix, I was aware of this and asked Thomas Petazzoni
and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
yesterday [1]

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-28  5:33 Stephen Rothwell
  2015-07-28 16:34 ` Luis R. Rodriguez
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-07-28  5:33 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Luis R. Rodriguez

Hi all,

After merging the tip tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
  ^
drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
                   ^

Caused by commits

  3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
  8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")

The latter defines ioremap_uc() for x86 and those architectures that
use asm-generic/io.h - which is not all of them :-( .  The former commit
then uses ioremap_uc().

I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-28  2:43 Stephen Rothwell
  2015-07-28  8:41 ` Sudeep Holla
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-07-28  2:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Jason Cooper, andrew, gregory.clement, linux-arm-kernel
  Cc: linux-next, linux-kernel, Sudeep Holla

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
   ^

Caused by commit

  e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")

from the mvebu tree interacting with commit

  0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")

from the tip tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Jul 2015 12:26:21 +1000
Subject: [PATCH] irqchip/gic: merge fix for "Remove redundant gic_set_irqchip_flags"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mach-mvebu/board-v7.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a6d2b4d6701a..b5ef80f369e7 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
 
 static void __init mvebu_init_irq(void)
 {
-	struct device_node *np;
-
-	np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-gic");
-	if (np)
-		gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
-				      IRQCHIP_MASK_ON_SUSPEND);
-	of_node_put(np);
 	irqchip_init();
 	mvebu_scu_enable();
 	coherency_init();
-- 
2.4.6

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-15  1:01 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-07-15  1:01 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Julia Lawall, Jiang Liu, Linus Walleij,
	linux-gpio

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pinctrl/sirf/pinctrl-atlas7.c: In function 'atlas7_gpio_handle_irq':
drivers/pinctrl/sirf/pinctrl-atlas7.c:4300:20: error: 'irq' undeclared (first use in this function)
   if (bank->irq == irq)
                    ^

Caused by commit

  5dc1aeb0340f ("pinctrl/sirf: Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch")
[hmmm, not a wonderful commit summary line]

I tried to use the tip tree from next-20150714, but for some reason that
broke the perf build:

  BUILD:   Doing 'make -j48' parallel build
make[3]: *** No rule to make target '../lib/hweight.c', needed by '/scratch/sfr/next/tools/perf/util/hweight.o'.  Stop.

So instead, I applied the following fix patch for today's issue:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 15 Jul 2015 10:56:28 +1000
Subject: [PATCH] pinctrl/sirf: fix for Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index f55c931f1088..7917b7719939 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -4294,6 +4294,7 @@ static void atlas7_gpio_handle_irq(unsigned int __irq, struct irq_desc *desc)
 	u32 status, ctrl;
 	int pin_in_bank = 0, idx;
 	struct irq_chip *chip = irq_desc_get_chip(desc);
+	unsigned int irq = irq_desc_get_irq(desc);
 
 	for (idx = 0; idx < a7gc->nbank; idx++) {
 		bank = &a7gc->banks[idx];
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-08  0:56 Stephen Rothwell
@ 2015-07-08  9:40 ` Thomas Gleixner
  0 siblings, 0 replies; 245+ messages in thread
From: Thomas Gleixner @ 2015-07-08  9:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

On Wed, 8 Jul 2015, Stephen Rothwell wrote:
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/cpu.c: In function '_cpu_down':
> kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration]
>   irq_lock_sparse();
>   ^
> kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
>    irq_unlock_sparse();
>    ^
> 
> Caused by commit
> 
>   fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down")
> 
> Forgot to include linux/irqdesc.h.
> 
> I have used the tip tree from next-20150707 for today.

Fixed in tip. Sorry for the hickup.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-08  0:56 Stephen Rothwell
  2015-07-08  9:40 ` Thomas Gleixner
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-07-08  0:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

kernel/cpu.c: In function '_cpu_down':
kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration]
  irq_lock_sparse();
  ^
kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
   irq_unlock_sparse();
   ^

Caused by commit

  fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down")

Forgot to include linux/irqdesc.h.

I have used the tip tree from next-20150707 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* RE: linux-next: build failure after merge of the tip tree
  2015-06-12 21:22   ` David Miller
@ 2015-06-12 21:25     ` Chickles, Derek
  0 siblings, 0 replies; 245+ messages in thread
From: Chickles, Derek @ 2015-06-12 21:25 UTC (permalink / raw)
  To: David Miller
  Cc: mpe, tglx, mingo, hpa, peterz, linux-next, linux-kernel, sfr,
	Burla, Satananda, Manlunas, Felix, Richter, Robert, Makarov,
	Aleksey, Vatsavayi, Raghu



> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
>  ...
> > Thanks. Much appreciated.
> 
> This doesn't work, neither of these emails are a formal proper submission
> of a fix for this build failure.
> 
> One of you has to do the work to formally submit the patch to netdev
> with a full signoff and commit log message so that it gets fixed in my
> tree.
> 
> Thanks.

Yes, we're working on this. Hopefully, we'll have this submitted later today, with the build fix and sparse warning fixes.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
       [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
@ 2015-06-12 21:22   ` David Miller
  2015-06-12 21:25     ` Chickles, Derek
  0 siblings, 1 reply; 245+ messages in thread
From: David Miller @ 2015-06-12 21:22 UTC (permalink / raw)
  To: Derek.Chickles
  Cc: mpe, tglx, mingo, hpa, peterz, linux-next, linux-kernel, sfr,
	Satananda.Burla, Felix.Manlunas, Robert.Richter, Aleksey.Makarov,
	Raghu.Vatsavayi

From: "Chickles, Derek" <Derek.Chickles@caviumnetworks.com>
Date: Fri, 12 Jun 2015 15:59:54 +0000

>> -----Original Message-----
>> From: Michael Ellerman [mailto:mpe@ellerman.id.au]
>> Sent: Friday, June 12, 2015 3:51 AM
>> To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; David
>> S.Miller
>> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org;
>> sfr@canb.auug.org.au; Chickles, Derek; Burla, Satananda; Manlunas, Felix;
>> Richter, Robert; Makarov, Aleksey; Vatsavayi, Raghu
>> Subject: linux-next: build failure after merge of the tip tree
>> 
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (x86_allmodconfig)
>> failed like this:
 ...
>> And so on.
>> 
>> Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
>> <linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit
>> f21fb3ed364b
>> "Add support of Cavium Liquidio ethernet adapters" from the net-next tree.
>> 
>> I applied the following fix for today:
 ...
> Thanks. Much appreciated.

This doesn't work, neither of these emails are a formal proper submission
of a fix for this build failure.

One of you has to do the work to formally submit the patch to netdev
with a full signoff and commit log message so that it gets fixed in my
tree.

Thanks.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-06-12 10:51 Michael Ellerman
       [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
  0 siblings, 1 reply; 245+ messages in thread
From: Michael Ellerman @ 2015-06-12 10:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David S.Miller
  Cc: linux-next, linux-kernel, sfr, derek.chickles, satananda.burla,
	felix.manlunas, Robert.Richter, Aleksey.Makarov, raghu.vatsavayi

Hi all,

After merging the tip tree, today's linux-next build (x86_allmodconfig)
failed like this:

  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_init_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:111:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
    iq->request_list = vmalloc(sizeof(*iq->request_list) * num_descs);
    ^
  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_delete_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:178:3: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
     vfree(iq->request_list);
     ^
  drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 'octeon_free_device_mem':
  drivers/net/ethernet/cavium/liquidio/octeon_device.c:653:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
      vfree(oct->droq[i]);
      ^

And so on.

Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
<linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit f21fb3ed364b
"Add support of Cavium Liquidio ethernet adapters" from the net-next tree.

I applied the following fix for today:

diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 2ca91657295f..4e581facae2c 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -27,6 +27,7 @@
 #include <linux/crc32.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index 60a186f1609b..94b502a0cf33 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -25,6 +25,7 @@
 #include <linux/pci.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index adb428463495..cd58660dd161 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -26,6 +26,7 @@
 #include <linux/pci.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"


cheers

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-06-09  7:15 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-06-09  7:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/kernel.h:13:0,
                 from include/linux/interrupt.h:5,
                 from drivers/iommu/intel_irq_remapping.c:4:
drivers/iommu/intel_irq_remapping.c: In function 'intel_enable_irq_remapping':
drivers/iommu/intel_irq_remapping.c:656:48: error: 'eim' undeclared (first use in this function)
  pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
                                                ^

Caused by my mismerge :-(

I added this merge fix patch (and will fix the merge itself tomorrow):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jun 2015 17:12:00 +1000
Subject: [PATCH] iommu.vt-d: fix mismerge

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/iommu/intel_irq_remapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
index 0d2500d17a2f..c19918471b3a 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -653,7 +653,7 @@ static int __init intel_enable_irq_remapping(void)
 
 	irq_remapping_enabled = 1;
 
-	pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
+	pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic");
 
 	return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-08  5:03             ` Stephen Rothwell
@ 2015-04-15  1:25               ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-04-15  1:25 UTC (permalink / raw)
  To: Daniel Borkmann, davem
  Cc: Alexei Starovoitov, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Steven Rostedt, Masami Hiramatsu, netdev

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

Hi all,

On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> > >> [ Cc'ing Dave, fyi ]
> > >>
> > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> > >>> <daniel@iogearbox.net> wrote:
> > >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >>>>>
> > >>>>>> After merging the tip tree, today's linux-next build (powerpc
> > >>>>>> ppc64_defconfig) failed like this:
> > >>>>>>
> > >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> > >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> > >>>>>> member named 'prog_type'
> > >>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>>>>                  ^
> > >>>>>>
> > >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> > >>>>>> attached to kprobes").
> > >>>>>
> > >>>>> Note, this must be some (rarely triggered) aspect of the ppc64
> > >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
> > >>>>> expose?
> > >>>>
> > >>>> Note, this is a merge conflict with the work that went via net-next
> > >>>> tree,
> > >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> > >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> > >>>>
> > >>>> You should be able to resolve it in linux-next by changing the test to:
> > >>>>
> > >>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>
> > >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> > >>> to tell Linus.
> > >>
> > >> Yes, indeed, depending which tree is merged first.
> > >
> > > Daniel analysis is correct, but the fix for kernel/events/core.c
> > > should be:
> > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > > instead of 'prog->prog_type'
> > 
> > Yes, absolutely, thanks!
> 
> So I have applied that as a merge fix patch.

This patch is now needed when the net-next tree is merged with Linus'
tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 15:08       ` Russell King - ARM Linux
  2015-03-30 15:24         ` Nathan Lynch
@ 2015-04-13 23:34         ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-04-13 23:34 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Nathan Lynch, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Hi Russell,

On Mon, 30 Mar 2015 16:08:38 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> > On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > > Hi Russell,
> > > 
> > > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > >>
> > >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> > >> it in my tree and keep my tree buildable without dragging in the tip
> > >> tree.
> > > 
> > > Does it affect your tree on its own?  If not, then it can be fixed when
> > > merged as I have done, or if you look at the tip tree, all you really
> > > need to merge is tip timers/core branch (which I am sure the tip guys
> > > can tell you if it is stable enough) which is about 28 commits ...
> > > 
> > >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > > 
> > > If that works for you.
> > 
> > FWIW, Stephen's merge fix is correct and I have run my vdso tests
> > without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

This patch is now needed when the arm tree is merged with Linus' tree
(the tip tree part has been merged).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 19:54           ` Daniel Borkmann
@ 2015-04-08  5:03             ` Stephen Rothwell
  2015-04-15  1:25               ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-04-08  5:03 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Alexei Starovoitov, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Steven Rostedt, Masami Hiramatsu, davem

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

Hi all,

On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> >> [ Cc'ing Dave, fyi ]
> >>
> >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> >>> <daniel@iogearbox.net> wrote:
> >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>>>
> >>>>>> After merging the tip tree, today's linux-next build (powerpc
> >>>>>> ppc64_defconfig) failed like this:
> >>>>>>
> >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> >>>>>> member named 'prog_type'
> >>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>>>>                  ^
> >>>>>>
> >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >>>>>> attached to kprobes").
> >>>>>
> >>>>> Note, this must be some (rarely triggered) aspect of the ppc64
> >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
> >>>>> expose?
> >>>>
> >>>> Note, this is a merge conflict with the work that went via net-next
> >>>> tree,
> >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> >>>>
> >>>> You should be able to resolve it in linux-next by changing the test to:
> >>>>
> >>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>
> >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> >>> to tell Linus.
> >>
> >> Yes, indeed, depending which tree is merged first.
> >
> > Daniel analysis is correct, but the fix for kernel/events/core.c
> > should be:
> > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > instead of 'prog->prog_type'
> 
> Yes, absolutely, thanks!

So I have applied that as a merge fix patch.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 16:18         ` Alexei Starovoitov
@ 2015-04-07 19:54           ` Daniel Borkmann
  2015-04-08  5:03             ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Daniel Borkmann @ 2015-04-07 19:54 UTC (permalink / raw)
  To: Alexei Starovoitov, Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Steven Rostedt,
	Masami Hiramatsu, davem

On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> On 4/7/15 4:13 AM, Daniel Borkmann wrote:
>> [ Cc'ing Dave, fyi ]
>>
>> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>>> <daniel@iogearbox.net> wrote:
>>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>
>>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>>> ppc64_defconfig) failed like this:
>>>>>>
>>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>>> member named 'prog_type'
>>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>>>                  ^
>>>>>>
>>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>>> attached to kprobes").
>>>>>
>>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>>> expose?
>>>>
>>>> Note, this is a merge conflict with the work that went via net-next
>>>> tree,
>>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>>
>>>> You should be able to resolve it in linux-next by changing the test to:
>>>>
>>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>
>>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
>>> to tell Linus.
>>
>> Yes, indeed, depending which tree is merged first.
>
> Daniel analysis is correct, but the fix for kernel/events/core.c
> should be:
> - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> instead of 'prog->prog_type'

Yes, absolutely, thanks!

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 11:13       ` Daniel Borkmann
@ 2015-04-07 16:18         ` Alexei Starovoitov
  2015-04-07 19:54           ` Daniel Borkmann
  0 siblings, 1 reply; 245+ messages in thread
From: Alexei Starovoitov @ 2015-04-07 16:18 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Steven Rostedt,
	Masami Hiramatsu, davem

On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> [ Cc'ing Dave, fyi ]
>
> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>> <daniel@iogearbox.net> wrote:
>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>> member named 'prog_type'
>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>>                  ^
>>>>>
>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>> attached to kprobes").
>>>>
>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>> expose?
>>>
>>> Note, this is a merge conflict with the work that went via net-next
>>> tree,
>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>
>>> You should be able to resolve it in linux-next by changing the test to:
>>>
>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>
>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
>> to tell Linus.
>
> Yes, indeed, depending which tree is merged first.

Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog->prog_type'

Thanks Stephen!

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  9:05     ` Stephen Rothwell
@ 2015-04-07 11:13       ` Daniel Borkmann
  2015-04-07 16:18         ` Alexei Starovoitov
  0 siblings, 1 reply; 245+ messages in thread
From: Daniel Borkmann @ 2015-04-07 11:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alexei Starovoitov,
	Steven Rostedt, Masami Hiramatsu, davem

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> After merging the tip tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) failed like this:
>>>>
>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>                  ^
>>>>
>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>> attached to kprobes").
>>>
>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>> expose?
>>
>> Note, this is a merge conflict with the work that went via net-next tree,
>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>
>> You should be able to resolve it in linux-next by changing the test to:
>>
>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>
> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> to tell Linus.

Yes, indeed, depending which tree is merged first.

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  8:56   ` Daniel Borkmann
@ 2015-04-07  9:05     ` Stephen Rothwell
  2015-04-07 11:13       ` Daniel Borkmann
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-04-07  9:05 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alexei Starovoitov,
	Steven Rostedt, Masami Hiramatsu

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

Hi Daniel,

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> After merging the tip tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
> >>    if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>                 ^
> >>
> >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >> attached to kprobes").
> >
> > Note, this must be some (rarely triggered) aspect of the ppc64
> > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > expose?
> 
> Note, this is a merge conflict with the work that went via net-next tree,
> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> 
> You should be able to resolve it in linux-next by changing the test to:
> 
>    if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  8:48 ` Ingo Molnar
@ 2015-04-07  8:56   ` Daniel Borkmann
  2015-04-07  9:05     ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Daniel Borkmann @ 2015-04-07  8:56 UTC (permalink / raw)
  To: Ingo Molnar, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>>    if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>                 ^
>>
>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>> attached to kprobes").
>
> Note, this must be some (rarely triggered) aspect of the ppc64
> defconfig that neither x86 randconfigs nor most other arch defconfigs
> expose?

Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

   if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  7:18 Stephen Rothwell
  2015-04-07  8:48 ` Ingo Molnar
@ 2015-04-07  8:53 ` Peter Zijlstra
  1 sibling, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2015-04-07  8:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

On Tue, Apr 07, 2015 at 05:18:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>                ^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").
> 
> I have used the tip tree from next-20150402 for today.

Hmm, tip/master builds fine on ppc64 for me, but does something like the
below help?

---
Subject: perf: Fix BPF filter crud

The BPF filter crud got its CONFIG deps wrong, fix it.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/events/core.c |   37 ++++++++++++++++++++++---------------
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 06917d5..1d94b92 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6711,6 +6711,25 @@ static void perf_event_free_filter(struct perf_event *event)
 	ftrace_profile_free_filter(event);
 }
 
+#else /* EVENT_TRACING */
+
+static inline void perf_tp_register(void)
+{
+}
+
+static int perf_event_set_filter(struct perf_event *event, void __user *arg)
+{
+	return -ENOENT;
+}
+
+static void perf_event_free_filter(struct perf_event *event)
+{
+}
+
+#endif /* EVENT_TRACING */
+
+#if defined CONFIG_BPF_EVENTS && defined CONFIG_EVENT_TRACING
+
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
 	struct bpf_prog *prog;
@@ -6754,20 +6773,7 @@ static void perf_event_free_bpf_prog(struct perf_event *event)
 	}
 }
 
-#else
-
-static inline void perf_tp_register(void)
-{
-}
-
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-	return -ENOENT;
-}
-
-static void perf_event_free_filter(struct perf_event *event)
-{
-}
+#else /* BPF_EVENTS && EVENT_TRACING */
 
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
@@ -6777,7 +6783,8 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 static void perf_event_free_bpf_prog(struct perf_event *event)
 {
 }
-#endif /* CONFIG_EVENT_TRACING */
+
+#endif /* BPF_EVENTS && EVENT_TRACING */
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
 void perf_bp_event(struct perf_event *bp, void *data)

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  7:18 Stephen Rothwell
@ 2015-04-07  8:48 ` Ingo Molnar
  2015-04-07  8:56   ` Daniel Borkmann
  2015-04-07  8:53 ` Peter Zijlstra
  1 sibling, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2015-04-07  8:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>                ^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").

Note, this must be some (rarely triggered) aspect of the ppc64 
defconfig that neither x86 randconfigs nor most other arch defconfigs 
expose?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-04-07  7:18 Stephen Rothwell
  2015-04-07  8:48 ` Ingo Molnar
  2015-04-07  8:53 ` Peter Zijlstra
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2015-04-07  7:18 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
  if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
               ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").

I have used the tip tree from next-20150402 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 15:08       ` Russell King - ARM Linux
@ 2015-03-30 15:24         ` Nathan Lynch
  2015-04-13 23:34         ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Nathan Lynch @ 2015-03-30 15:24 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
>> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
>>> Hi Russell,
>>>
>>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>>>
>>>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>>>> it in my tree and keep my tree buildable without dragging in the tip
>>>> tree.
>>>
>>> Does it affect your tree on its own?  If not, then it can be fixed when
>>> merged as I have done, or if you look at the tip tree, all you really
>>> need to merge is tip timers/core branch (which I am sure the tip guys
>>> can tell you if it is stable enough) which is about 28 commits ...
>>>
>>>> The ARM VDSO stuff will just have to wait for 4.2 instead.
>>>
>>> If that works for you.
>>
>> FWIW, Stephen's merge fix is correct and I have run my vdso tests
>> without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

OK, let me know if I can help.

I'm happy to remind you about it when the merge window opens.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 14:57     ` Nathan Lynch
@ 2015-03-30 15:08       ` Russell King - ARM Linux
  2015-03-30 15:24         ` Nathan Lynch
  2015-04-13 23:34         ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Russell King - ARM Linux @ 2015-03-30 15:08 UTC (permalink / raw)
  To: Nathan Lynch
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > Hi Russell,
> > 
> > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >>
> >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> >> it in my tree and keep my tree buildable without dragging in the tip
> >> tree.
> > 
> > Does it affect your tree on its own?  If not, then it can be fixed when
> > merged as I have done, or if you look at the tip tree, all you really
> > need to merge is tip timers/core branch (which I am sure the tip guys
> > can tell you if it is stable enough) which is about 28 commits ...
> > 
> >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > 
> > If that works for you.
> 
> FWIW, Stephen's merge fix is correct and I have run my vdso tests
> without problems on OMAP5 with next-20150330.

Hopefully, I can pull the tip stuff but if not, I'll try to remember
to include Stephen's patch with my pull request, but I can't make any
guarantees - Stephen's email will very quickly get buried in my mailbox,
and I'll most likely forget about it too... I'm notoriously bad with
email...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  8:08   ` Stephen Rothwell
@ 2015-03-30 14:57     ` Nathan Lynch
  2015-03-30 15:08       ` Russell King - ARM Linux
  0 siblings, 1 reply; 245+ messages in thread
From: Nathan Lynch @ 2015-03-30 14:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Russell King - ARM Linux, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> Hi Russell,
> 
> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>
>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>> it in my tree and keep my tree buildable without dragging in the tip
>> tree.
> 
> Does it affect your tree on its own?  If not, then it can be fixed when
> merged as I have done, or if you look at the tip tree, all you really
> need to merge is tip timers/core branch (which I am sure the tip guys
> can tell you if it is stable enough) which is about 28 commits ...
> 
>> The ARM VDSO stuff will just have to wait for 4.2 instead.
> 
> If that works for you.

FWIW, Stephen's merge fix is correct and I have run my vdso tests
without problems on OMAP5 with next-20150330.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  7:15 ` Russell King - ARM Linux
@ 2015-03-30  8:08   ` Stephen Rothwell
  2015-03-30 14:57     ` Nathan Lynch
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-03-30  8:08 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nathan Lynch

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

Hi Russell,

On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> it in my tree and keep my tree buildable without dragging in the tip
> tree.

Does it affect your tree on its own?  If not, then it can be fixed when
merged as I have done, or if you look at the tip tree, all you really
need to merge is tip timers/core branch (which I am sure the tip guys
can tell you if it is stable enough) which is about 28 commits ...

> The ARM VDSO stuff will just have to wait for 4.2 instead.

If that works for you.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  6:13 Stephen Rothwell
@ 2015-03-30  7:15 ` Russell King - ARM Linux
  2015-03-30  8:08   ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Russell King - ARM Linux @ 2015-03-30  7:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nathan Lynch

On Mon, Mar 30, 2015 at 05:13:34PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
> arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr'
>   if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
>                ^
> arch/arm/kernel/vdso.c: In function 'update_vsyscall':
> arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_cycle_last = tk->tkr.cycle_last;
>                                 ^
> arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
>                                     ^
> arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_mult  = tk->tkr.mult;
>                            ^
> arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_shift  = tk->tkr.shift;
>                             ^
> arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_mask  = tk->tkr.mask;
>                            ^
> 
> Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
> timekeeper::tkr_mono") from the tip tree interacting with commit
> ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
> synchronization") from the arm tree.
> 
> I added this merge fix patch for today (is that all that is needed?):

I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
tree.

The ARM VDSO stuff will just have to wait for 4.2 instead.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-03-30  6:13 Stephen Rothwell
  2015-03-30  7:15 ` Russell King - ARM Linux
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2015-03-30  6:13 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Russell King
  Cc: linux-next, linux-kernel, Nathan Lynch

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr'
  if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
               ^
arch/arm/kernel/vdso.c: In function 'update_vsyscall':
arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_cycle_last = tk->tkr.cycle_last;
                                ^
arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
                                    ^
arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_mult  = tk->tkr.mult;
                           ^
arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_shift  = tk->tkr.shift;
                            ^
arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_mask  = tk->tkr.mask;
                           ^

Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
timekeeper::tkr_mono") from the tip tree interacting with commit
ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
synchronization") from the arm tree.

I added this merge fix patch for today (is that all that is needed?):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Mar 2015 17:08:21 +1100
Subject: [PATCH] ARM: VDSO: rename tkr to tkr_mono

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/kernel/vdso.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 0d31d3ccab81..efe17dd9b921 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
 	if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
 		return false;
 
-	if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
+	if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
 		return false;
 
 	return true;
@@ -316,12 +316,12 @@ void update_vsyscall(struct timekeeper *tk)
 	vdso_data->wtm_clock_nsec		= wtm->tv_nsec;
 
 	if (vdso_data->tk_is_cntvct) {
-		vdso_data->cs_cycle_last	= tk->tkr.cycle_last;
+		vdso_data->cs_cycle_last	= tk->tkr_mono.cycle_last;
 		vdso_data->xtime_clock_sec	= tk->xtime_sec;
-		vdso_data->xtime_clock_snsec	= tk->tkr.xtime_nsec;
-		vdso_data->cs_mult		= tk->tkr.mult;
-		vdso_data->cs_shift		= tk->tkr.shift;
-		vdso_data->cs_mask		= tk->tkr.mask;
+		vdso_data->xtime_clock_snsec	= tk->tkr_mono.xtime_nsec;
+		vdso_data->cs_mult		= tk->tkr_mono.mult;
+		vdso_data->cs_shift		= tk->tkr_mono.shift;
+		vdso_data->cs_mask		= tk->tkr_mono.mask;
 	}
 
 	vdso_write_end(vdso_data);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-07-29 23:56 ` Stephen Rothwell
@ 2014-07-30  3:10   ` John Stultz
  0 siblings, 0 replies; 245+ messages in thread
From: John Stultz @ 2014-07-30  3:10 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel

On 07/29/2014 04:56 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> arch/powerpc/kernel/time.c:743:6: error: conflicting types for
'update_vsyscall_old'
>>  void update_vsyscall_old(struct timespec *wall_time, struct timespec
*wtm,
>>       ^
>> In file included from arch/powerpc/kernel/time.c:77:0:
>> include/linux/timekeeper_internal.h:114:13: note: previous
declaration of 'update_vsyscall_old' was here
>>  extern void update_vsyscall_old(struct timespec *ts, struct timespec
*wtm,
>>              ^
>>
>> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
>>
>> I have used the tip tree from next-20140724 for today.
>
> Ping?
So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo
in update_vsyscall_old definition), but I've not heard anything from
anyone on it.


thanks
-john

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-07-25  4:45 Stephen Rothwell
@ 2014-07-29 23:56 ` Stephen Rothwell
  2014-07-30  3:10   ` John Stultz
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-07-29 23:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hi all,

On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old'
>  void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
>       ^
> In file included from arch/powerpc/kernel/time.c:77:0:
> include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here
>  extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
>              ^
> 
> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
> 
> I have used the tip tree from next-20140724 for today.

Ping?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-07-25  4:45 Stephen Rothwell
  2014-07-29 23:56 ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-07-25  4:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old'
 void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
      ^
In file included from arch/powerpc/kernel/time.c:77:0:
include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here
 extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
             ^

Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").

I have used the tip tree from next-20140724 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 16:23   ` Olof Johansson
@ 2014-06-04 20:02     ` Thomas Gleixner
  0 siblings, 0 replies; 245+ messages in thread
From: Thomas Gleixner @ 2014-06-04 20:02 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Linus Torvalds

On Wed, 4 Jun 2014, Olof Johansson wrote:
> On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> So, we'll dial back and stop taking these patches through our tree
> without an explicit ack or shared branch from you (or Daniel on
> clocksource). Not a problem at all.

I prefer the shared branch (for clocksource and irqchip) either from
me or from Daniel(clocksource) / Jason (irqchip).

That way you can proceed and we can do our unrelated changes without
creating merge dependencies.

> On the other hand, it would have been a lot easier
> to handle had the code on your end landed a bit sooner than in the
> middle of the merge window.

I know. I was just burried in futex wreckage for almost a week...

> Not much I can say besides what's above and that I owe you a few beers
> at the next conference.

Don't worry. I let off steam and all is good if we can avoid this in
the future. Though I'm certainly up for a few beers :)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 10:49 ` Thomas Gleixner
  2014-06-04 14:46   ` Linus Torvalds
@ 2014-06-04 16:23   ` Olof Johansson
  2014-06-04 20:02     ` Thomas Gleixner
  1 sibling, 1 reply; 245+ messages in thread
From: Olof Johansson @ 2014-06-04 16:23 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Linus Torvalds

On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 4 Jun 2014, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>>
>> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
>> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
>>
>> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
>> setup_sched_clock() API") from the tip tree.  The usage was only added
>> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
>> source for Versatile Express") (but this commit has been in linux-next
>> since May 22 at least).
>>
>> I have reverted the tip tree commit for today.
>
> Dammit. Why the heck can ARM folks not route their stuff through the
> relevant maintainers? Because ARM is a different universe with
> different rules or what?

We talked about this as late as February this year. It's has been a
long-standing issue that we've struggled with how we should manage.

When I talked to you about it (irqchip drivers at the time), you said
you were in general fine with us merging driver patches when someone
times out waiting on you to review/merge a patch. My concern at the
time is that while we can look at the code of the patch and review
that, we don't have the larger picture of what's going on in the
subsystem. Which is what caused problems here, I'd say.

So, we'll dial back and stop taking these patches through our tree
without an explicit ack or shared branch from you (or Daniel on
clocksource). Not a problem at all.

> Of course this crap is already in Linus next branch, so it essentially
> blocks me from sending my pending timers/core branch.

We obviously never intended to cause any problems like these, and I
apologize for that. On the other hand, it would have been a lot easier
to handle had the code on your end landed a bit sooner than in the
middle of the merge window.

> Patch below. Linus, can you please apply this?
>
> I've ranted about this before. It's not the first time that ARM breaks
> stuff I maintain.
>
> Again: Send your stuff against drivers/clocksource and drivers/irqchip
> to the maintainers.
>
> I'm happy to provide you a separate branch to pull that stuff from me,
> if you have dependencies on that, but I really don't want to see any
> of this again, ever.
>
> Yours seriously grumpy

Not much I can say besides what's above and that I owe you a few beers
at the next conference.


-Olof

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 10:49 ` Thomas Gleixner
@ 2014-06-04 14:46   ` Linus Torvalds
  2014-06-04 16:23   ` Olof Johansson
  1 sibling, 0 replies; 245+ messages in thread
From: Linus Torvalds @ 2014-06-04 14:46 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Olof Johansson

On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Patch below. Linus, can you please apply this?

Done.

           Linus

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04  6:05 Stephen Rothwell
@ 2014-06-04 10:49 ` Thomas Gleixner
  2014-06-04 14:46   ` Linus Torvalds
  2014-06-04 16:23   ` Olof Johansson
  0 siblings, 2 replies; 245+ messages in thread
From: Thomas Gleixner @ 2014-06-04 10:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next, LKML,
	Pawel Moll, Stephen Boyd, John Stultz, Olof Johansson,
	Linus Torvalds

On Wed, 4 Jun 2014, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> 
> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
> 
> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
> setup_sched_clock() API") from the tip tree.  The usage was only added
> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
> source for Versatile Express") (but this commit has been in linux-next
> since May 22 at least).
> 
> I have reverted the tip tree commit for today.

Dammit. Why the heck can ARM folks not route their stuff through the
relevant maintainers? Because ARM is a different universe with
different rules or what?

Of course this crap is already in Linus next branch, so it essentially
blocks me from sending my pending timers/core branch.

Patch below. Linus, can you please apply this?

I've ranted about this before. It's not the first time that ARM breaks
stuff I maintain.

Again: Send your stuff against drivers/clocksource and drivers/irqchip
to the maintainers. 

I'm happy to provide you a separate branch to pull that stuff from me,
if you have dependencies on that, but I really don't want to see any
of this again, ever.

Yours seriously grumpy

      tglx

------------>
Subject: clocksource: versatile: Use sched_clock_register()
From: Thomas Gleixner <tglx@linutronix.de>
Date: Wed, 04 Jun 2014 12:34:15 +0200

The newly merged versatile sched clock support uses a deprecated
interface. Of course that patch got routed through the ARM tree
instead of going through the relevant maintainer tree.

Use the proper interface so we can get rid of the cruft.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
index e4c50ad..2798e74 100644
--- a/drivers/clocksource/versatile.c
+++ b/drivers/clocksource/versatile.c
@@ -20,7 +20,7 @@
 
 static void __iomem *versatile_sys_24mhz;
 
-static u32 notrace versatile_sys_24mhz_read(void)
+static u64 notrace versatile_sys_24mhz_read(void)
 {
 	return readl(versatile_sys_24mhz);
 }
@@ -34,7 +34,7 @@ static void __init versatile_sched_clock_init(struct device_node *node)
 
 	versatile_sys_24mhz = base + SYS_24MHZ;
 
-	setup_sched_clock(versatile_sys_24mhz_read, 32, 24000000);
+	sched_clock_register(versatile_sys_24mhz_read, 32, 24000000);
 }
 CLOCKSOURCE_OF_DECLARE(versatile, "arm,vexpress-sysreg",
-		versatile_sched_clock_init);
+		       versatile_sched_clock_init);

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-06-04  6:05 Stephen Rothwell
  2014-06-04 10:49 ` Thomas Gleixner
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-06-04  6:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Pawel Moll, Stephen Boyd, John Stultz

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:


drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]

Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
setup_sched_clock() API") from the tip tree.  The usage was only added
to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
source for Versatile Express") (but this commit has been in linux-next
since May 22 at least).

I have reverted the tip tree commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-05-23  7:14 Stephen Rothwell
@ 2014-05-29  1:38 ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2014-05-29  1:38 UTC (permalink / raw)
  To: Russell King
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

Hi Russell,

On Fri, 23 May 2014 17:14:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from arch/arm/include/asm/outercache.h:24:0,
>                  from arch/arm/include/asm/barrier.h:5,
>                  from arch/arm/include/asm/bitops.h:28,
>                  from include/linux/bitops.h:33,
>                  from include/linux/kernel.h:10,
>                  from include/asm-generic/bug.h:13,
>                  from arch/arm/include/asm/bug.h:61,
>                  from arch/arm/include/asm/div64.h:63,
>                  from include/linux/math64.h:5,
>                  from include/linux/jiffies.h:4,
>                  from init/calibrate.c:7:
> include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
> include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> include/linux/bug.h: In function 'is_warning_bug':
> include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
> 
>  ... and many, many more ...
> 
> Probably caused by commit 030d0178bdbd ("arch,arm: Convert
> smp_mb__*()") which added an include of asm/barrier.h to
> arch/arm/include/asm/bitops.h.  This has interacted with commit
> 59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()")
> from the arm tree, which adds an include of linux/bug.h to
> arch/arm/include/asm/outercache.h.
> 
> I added the below merge fix patch.  Russell, this should be applied to
> your tree directly.

Ping?  I am still carrying this patch ...

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 23 May 2014 17:10:12 +1000
> Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h
> 
> This fixes a cricular include dependency when combined with commits from
> the tip tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm/include/asm/outercache.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
> index eaa8a28c6871..891a56b35bcf 100644
> --- a/arch/arm/include/asm/outercache.h
> +++ b/arch/arm/include/asm/outercache.h
> @@ -21,7 +21,6 @@
>  #ifndef __ASM_OUTERCACHE_H
>  #define __ASM_OUTERCACHE_H
>  
> -#include <linux/bug.h>
>  #include <linux/types.h>
>  
>  struct outer_cache_fns {
> -- 
> 2.0.0.rc4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-05-23  7:14 Stephen Rothwell
  2014-05-29  1:38 ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-05-23  7:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Russell King
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/include/asm/outercache.h:24:0,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/kernel.h:10,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from arch/arm/include/asm/div64.h:63,
                 from include/linux/math64.h:5,
                 from include/linux/jiffies.h:4,
                 from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type

 ... and many, many more ...

Probably caused by commit 030d0178bdbd ("arch,arm: Convert
smp_mb__*()") which added an include of asm/barrier.h to
arch/arm/include/asm/bitops.h.  This has interacted with commit
59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()")
from the arm tree, which adds an include of linux/bug.h to
arch/arm/include/asm/outercache.h.

I added the below merge fix patch.  Russell, this should be applied to
your tree directly.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 May 2014 17:10:12 +1000
Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h

This fixes a cricular include dependency when combined with commits from
the tip tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/outercache.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
 #ifndef __ASM_OUTERCACHE_H
 #define __ASM_OUTERCACHE_H
 
-#include <linux/bug.h>
 #include <linux/types.h>
 
 struct outer_cache_fns {
-- 
2.0.0.rc4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-04-24  3:51 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2014-04-24  3:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Russell King

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/include/asm/outercache.h:24:0,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/kernel.h:10,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from arch/arm/include/asm/div64.h:63,
                 from include/linux/math64.h:5,
                 from include/linux/jiffies.h:4,
                 from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
In file included from include/linux/kernel.h:11:0,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from include/linux/bug.h:4,
                 from arch/arm/include/asm/outercache.h:24,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/signal.h:35,
                 from arch/arm/kernel/signal.c:12:
include/linux/log2.h: In function '__ilog2_u32':
include/linux/log2.h:34:2: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__ilog2_u64':
include/linux/log2.h:42:2: error: implicit declaration of function 'fls64' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__roundup_pow_of_two':
include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long' [-Werror=implicit-function-declaration]
In file included from include/linux/bitops.h:33:0,
                 from include/linux/signal.h:35,
                 from arch/arm/kernel/signal.c:12:
arch/arm/include/asm/bitops.h: At top level:
arch/arm/include/asm/bitops.h:273:19: error: static declaration of 'fls' follows non-static declaration
include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here

And many more ...

Guessing ... caused by commit febdbfe8a91c ("arch: Prepare for smp_mb__
{before,after}_atomic()") and following interacting with commit
735e532e0f25 ("ARM: outer cache: add WARN_ON() to outer_disable()") from
the arm tree?

I applied this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Apr 2014 13:46:08 +1000
Subject: [PATCH] ARM: outer cache: remove include of linux/bug.h from outercache.h

It causes a circular inclusion and looks like it is not necessary anyway.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/outercache.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
 #ifndef __ASM_OUTERCACHE_H
 #define __ASM_OUTERCACHE_H
 
-#include <linux/bug.h>
 #include <linux/types.h>
 
 struct outer_cache_fns {
-- 
2.0.0.rc0

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-02-12  2:41 Stephen Rothwell
@ 2014-02-12  4:48 ` Preeti U Murthy
  0 siblings, 0 replies; 245+ messages in thread
From: Preeti U Murthy @ 2014-02-12  4:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nicolas Pitre

Hi Stephen,

On 02/12/2014 08:11 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
> drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration]
>   ppc64_runlatch_off();
>   ^
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog':
> drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration]
>   ppc64_runlatch_on();
>   ^
> 
> Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant
> cpuidle_idle_call()").

Ok so after the commit

d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()
reintroduced ppc64_runlatch_off/on() in drivers/cpuidle/cpuidle-pseries.c
the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines"
now needs to be introduced in part.

Below is the patch which should fix this. This is based on top of tip-tree.

Thanks

Regards
Preeti U Murthy

---------------------------------------------------------------------------------

cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend driver

From: Preeti U Murthy <preeti@linux.vnet.ibm.com>

Commit "d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()"
reintroduced ppc64_runlatch_off/on() in the pseries cpuidle backend driver.
Hence the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines"  in
conjuction with the commit d8c6ad3184ca651 causes a build failure.

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
 drivers/cpuidle/cpuidle-pseries.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index d486489..6f7b019 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -17,6 +17,7 @@
 #include <asm/reg.h>
 #include <asm/machdep.h>
 #include <asm/firmware.h>
+#include <asm/runlatch.h>
 #include <asm/plpar_wrappers.h>
 
 struct cpuidle_driver pseries_idle_driver = {


> 
> I have used the tip tree from next-20140210 again today (since
> next-20140211 was broken differently).
> 

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-02-12  2:41 Stephen Rothwell
  2014-02-12  4:48 ` Preeti U Murthy
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-02-12  2:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Nicolas Pitre, Preeti U Murthy

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration]
  ppc64_runlatch_off();
  ^
drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog':
drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration]
  ppc64_runlatch_on();
  ^

Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant
cpuidle_idle_call()").

I have used the tip tree from next-20140210 again today (since
next-20140211 was broken differently).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-02-11  3:00 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2014-02-11  3:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dongsheng Yang

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: "MAX_USER_PRIO" redefined [-Werror]
 #define MAX_USER_PRIO  (MAX_PRIO - MAX_RT_PRIO)
 ^
In file included from include/linux/sched.h:6:0,
                 from arch/powerpc/platforms/cell/spufs/sched.c:26:
include/linux/sched/prio.h:38:0: note: this is the location of the previous definition
 #define MAX_USER_PRIO  (USER_PRIO(MAX_PRIO))
 ^

Caused by commit 6b6350f155af ("sched: Expose some macros related to
priority").  A quick grep shows that MAX_USER_PRIO is defined in
include/linux/sched/prio.h, but not used anywhere (except in
arch/powerpc/platforms/cell/spufs/sched.c where it is also defined)?

I have used the tip tree from next-20140210 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:51                   ` Peter Zijlstra
  2014-01-21  3:26                     ` Mike Galbraith
@ 2014-01-21 10:47                     ` Ingo Molnar
  1 sibling, 0 replies; 245+ messages in thread
From: Ingo Molnar @ 2014-01-21 10:47 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, H. Peter Anvin, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > > As a side note, at minimum the semantic and compatibility difference
> > > needs to be _very_ clearly present in the naming. Something like
> > > mwait_old_() or mwait_core2_(). That way such dependencies and
> > > assumptions don't get lost in code restructuring, etc.
> > 
> > Agreed.
> > We started with mwait_idle() -- which was erroneously removed
> > and is now being restored under it original name.
> > 
> > The "new" function is mwait_idle_with_hints() -- which uses the 
> > additional hints that were not available w/ the original MWAIT 
> > instruction. Where "new" is Core Duo and later -- all the 
> > processor that can use MWAIT for C-states deeper than C1.
> 
> I'm still waiting for someone to explain what's wrong with:
> 
> static inline void mwait_idle(void)
> {
> 	local_irq_enable();
> 	mwait_idle_with_hints(0, 0);
> }

Absolutely agreed, we don't want to carry it on 'just because', the 
compatibility aspect needs to be documented - otherwise we degrade 
into cargo cult programming.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:51                   ` Peter Zijlstra
@ 2014-01-21  3:26                     ` Mike Galbraith
  2014-01-21 10:47                     ` Ingo Molnar
  1 sibling, 0 replies; 245+ messages in thread
From: Mike Galbraith @ 2014-01-21  3:26 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Ingo Molnar, H. Peter Anvin, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On Mon, 2014-01-20 at 22:51 +0100, Peter Zijlstra wrote:

> I'm still waiting for someone to explain what's wrong with:
> 
> static inline void mwait_idle(void)
> {
> 	local_irq_enable();
> 	mwait_idle_with_hints(0, 0);
> }

How about just do that going forward, it work, and can always be fixed
if something turns up, and the below for stable once it hits mainline?

Q6600 box is happy camper in all trees.

From: Len Brown <len.brown@intel.com>

x86 idle: restore mwait_idle()

In Linux-3.9 we removed the mwait_idle() loop:
'x86 idle: remove mwait_idle() and "idle=mwait" cmdline param'
(69fb3676df3329a7142803bb3502fa59dc0db2e3)

The reasoning was that modern machines should be sufficiently
happy during the boot process using the default_idle() HALT loop,
until cpuidle loads and either acpi_idle or intel_idle
invoke the newer MWAIT-with-hints idle loop.

But two machines reported problems:
1. Certain Core2-era machines support MWAIT-C1 and HALT only.
   MWAIT-C1 is preferred for optimal power and performance.
   But if they support just C1, cpuidle never loads and
   so they use the boot-time default idle loop forever.

2. Some laptops will boot-hang if HALT is used,
   but will boot successfully if MWAIT is used.
   This appears to be a hidden assumption in BIOS SMI,
   that is presumably valid on the proprietary OS
   where the BIOS was validated.

   https://bugzilla.kernel.org/show_bug.cgi?id=60770

So here we effectively revert the patch above, restoring
the mwait_idle() loop.  However, we don't bother restoring
the idle=mwait cmdline parameter, since it appears to add
no value.

Maintainer notes:
For 3.9, simply revert 69fb3676df
for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context
For 3.11, 3.12, 3.13, this patch applies cleanly

Mike: reinstate polling, and add clflush barriers.

Cc: Mike Galbraith <bitbucket@online.de>
Cc: Ian Malone <ibmalone@gmail.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org> # 3.9, 3.10, 3.11, 3.12, 3.13
Signed-off-by: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Len Brown <len.brown@intel.com>
---
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8b5..c5db2a43e730 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -398,6 +398,52 @@ static void amd_e400_idle(void)
 		default_idle();
 }
 
+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+	if (c->x86_vendor != X86_VENDOR_INTEL)
+		return 0;
+
+	if (!cpu_has(c, X86_FEATURE_MWAIT))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+
+static void mwait_idle(void)
+{
+	if (!current_set_polling_and_test()) {
+		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+			mb();
+			clflush((void *)&current_thread_info()->flags);
+			mb();
+		}
+
+		__monitor((void *)&current_thread_info()->flags, 0, 0);
+		if (!need_resched())
+			__sti_mwait(0, 0);
+		else
+			local_irq_enable();
+	} else
+		local_irq_enable();
+	__current_clr_polling();
+}
+
 void select_idle_routine(const struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
@@ -411,6 +457,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c)
 		/* E400: APIC timer interrupt does not wake up CPU from C1e */
 		pr_info("using AMD E400 aware idle routine\n");
 		x86_idle = amd_e400_idle;
+	} else if (prefer_mwait_c1_over_halt(c)) {
+		pr_info("using mwait in idle threads\n");
+		x86_idle = mwait_idle;
 	} else
 		x86_idle = default_idle;
 }
 

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:39                 ` Len Brown
@ 2014-01-20 21:51                   ` Peter Zijlstra
  2014-01-21  3:26                     ` Mike Galbraith
  2014-01-21 10:47                     ` Ingo Molnar
  0 siblings, 2 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20 21:51 UTC (permalink / raw)
  To: Len Brown
  Cc: Ingo Molnar, H. Peter Anvin, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel

On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > As a side note, at minimum the semantic and compatibility difference
> > needs to be _very_ clearly present in the naming. Something like
> > mwait_old_() or mwait_core2_(). That way such dependencies and
> > assumptions don't get lost in code restructuring, etc.
> 
> Agreed.
> We started with mwait_idle() -- which was erroneously removed
> and is now being restored under it original name.
> 
> The "new" function is mwait_idle_with_hints() -- which uses
> the additional hints that were not available w/ the original MWAIT instruction.
> Where "new" is Core Duo and later -- all the processor that can use
> MWAIT for C-states deeper than C1.

I'm still waiting for someone to explain what's wrong with:

static inline void mwait_idle(void)
{
	local_irq_enable();
	mwait_idle_with_hints(0, 0);
}

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:29               ` Ingo Molnar
@ 2014-01-20 21:39                 ` Len Brown
  2014-01-20 21:51                   ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Len Brown @ 2014-01-20 21:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: H. Peter Anvin, Peter Zijlstra, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

> As a side note, at minimum the semantic and compatibility difference
> needs to be _very_ clearly present in the naming. Something like
> mwait_old_() or mwait_core2_(). That way such dependencies and
> assumptions don't get lost in code restructuring, etc.

Agreed.
We started with mwait_idle() -- which was erroneously removed
and is now being restored under it original name.

The "new" function is mwait_idle_with_hints() -- which uses
the additional hints that were not available w/ the original MWAIT instruction.
Where "new" is Core Duo and later -- all the processor that can use
MWAIT for C-states deeper than C1.

Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 13:10                     ` Stephen Rothwell
@ 2014-01-20 15:28                       ` Sedat Dilek
  0 siblings, 0 replies; 245+ messages in thread
From: Sedat Dilek @ 2014-01-20 15:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 2:10 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Sedat,
>
> On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>
>> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>> >>>
>> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> >>> Q6600 box.  See below for an alternative.
>> >>>
>> >>> idle: kill unnecessary mwait_idle() resched IPIs
>> >>
>> >> OK, so despite even further discussion, I have applied this as a merge
>> >> fix patch for today.  Let me know when it is all sorted out.
>> >>
>> >
>> > Where is this fix?
>> > ( Browsing Linux-next remote GIT repository online. )
>> > 2x NOPE for me.
>> >
>> > - Sedat -
>> >
>> > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
>> > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
>> >
>>
>> Hmmm... Found this in Next/merge.log
>>
>> +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
>> +Applying: idle: kill unnecessary mwait_idle() resched IPIs
>> +$ git reset HEAD^
>> +Unstaged changes after reset:
>> +M arch/x86/include/asm/processor.h
>> +M arch/x86/kernel/process.c
>
> You missed the next three lines:
>
> $ git add -A .
> $ git commit -v -a --amend
> [master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest'
>

[ I was absent for a while from Linux-next, so I am asking for clarification. ]
[ I might be wrong. ]

What does that mean?
AFAICS you applied an important fix by yourself on top of tip/auto-latest?

>> Is this a local patch not shipped in the Linux-next (remote) GIT repo?
>> Why is this not in your next-fixes GIT repo?
>
> Its part of the conflict resolution for the merge of the tip tree.  It
> cannot go into my fixes tree - that is for fixes to bugs in Linus' tree
> until they are integrated there.  The tip and pm trees are both fine on
> their own, but combined they don't.  So this fix has to go into the actual
> merge commit for the merge of the later tree.   When Linus' merges the
> later of these trees he will also need this fix - or a better one - which
> is what is still under discussion.
>

I was asking in general about next-fixes to have a "bootable" (aka
working) Linux-next kernel.

You see next-fixes as a place to fix Linus-tree, seriously?

The question here in this special case seems to be a "logical"
(not-working-together) problem between tip and pm.

And we are in a merge-window...

>> A bit confused about your -next policies,
>
> Any better?
>

Not really.
You should clarify on what you are doing in your next-fixes tree.
Your daily report for Linux-next releases even does not mention next-fixes.

Looking through my INBOX Thierry had the initial idea of "fixes for
linux-next" when you were on vacation and he took over maintainership.

- Sedat -

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:46                   ` Sedat Dilek
@ 2014-01-20 13:10                     ` Stephen Rothwell
  2014-01-20 15:28                       ` Sedat Dilek
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-20 13:10 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi Sedat,

On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
> >>>
> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> >>> Q6600 box.  See below for an alternative.
> >>>
> >>> idle: kill unnecessary mwait_idle() resched IPIs
> >>
> >> OK, so despite even further discussion, I have applied this as a merge
> >> fix patch for today.  Let me know when it is all sorted out.
> >>
> >
> > Where is this fix?
> > ( Browsing Linux-next remote GIT repository online. )
> > 2x NOPE for me.
> >
> > - Sedat -
> >
> > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
> > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
> >
> 
> Hmmm... Found this in Next/merge.log
> 
> +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
> +Applying: idle: kill unnecessary mwait_idle() resched IPIs
> +$ git reset HEAD^
> +Unstaged changes after reset:
> +M arch/x86/include/asm/processor.h
> +M arch/x86/kernel/process.c

You missed the next three lines:

$ git add -A .
$ git commit -v -a --amend
[master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest'

> Is this a local patch not shipped in the Linux-next (remote) GIT repo?
> Why is this not in your next-fixes GIT repo?

Its part of the conflict resolution for the merge of the tip tree.  It
cannot go into my fixes tree - that is for fixes to bugs in Linus' tree
until they are integrated there.  The tip and pm trees are both fine on
their own, but combined they don't.  So this fix has to go into the actual
merge commit for the merge of the later tree.   When Linus' merges the
later of these trees he will also need this fix - or a better one - which
is what is still under discussion.

> A bit confused about your -next policies,

Any better?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 10:19       ` H. Peter Anvin
@ 2014-01-20 11:06         ` Peter Zijlstra
  0 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20 11:06 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 02:19:30AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> > On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> >> Then make them so. The fact was that most of the mwait idle sites
> >> were bloody broken. And the single mwait_idle_with_hints() function
> >> presents a single nice function that does all the required magics.
> > 
> > To stress this a bit more; have a look see at mwwait_idle_with_hints();
> > it does a whole lot of subtle magic.
> > 
> >  - current_{set,clr}_polling*(), these are crucial in not missing and
> >    wrecking NEED_RESCHED state.
> > 
> >  - X86_FEATURE_CLFLUSH_MONTIOR quirk
> > 
> >  - Does the monitor(); if (!need_resched()) mwait() thing.
> > 
> > All of those are required for a correct and functional idle loop. And
> > I've seen sites where any or all of the above were missing/broken.
> > 
> > Not unifying the lot into a simple usable function is just stupid --
> > history has shown people simply cannot be trusted to get this right.
> > 
> 
> I don't think anyone is arguing that.  The question is rather if the
> implementation is correct, and if it is ready for the merge window.

I've yet to hear an argument against it other than vaguaries.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 11:00                 ` H. Peter Anvin
@ 2014-01-20 11:05                   ` Peter Zijlstra
  0 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20 11:05 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 03:00:29AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> > 
> > Ok, so I still don't get the problem of enabling interrupts early.
> > 
> > If we enable them early we can get interrupts; which afaict fall into
> > two groups, those that do and do not set NEED_RESCHED.
> > 
> > For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> > and looped right back into it, so receiving those early -- before
> > actually calling MWAIT/HLT seems like a NO-OP.
> 
> The description for commit d331e739f5ad seems to indicate otherwise:
> 
>     Idle callbacks has some races when enter_idle() sets isidle and
> subsequent
>     interrupts that can happen on that CPU, before CPU goes to idle. Due
> to this,
>     an IDLE_END can get called before IDLE_START. To avoid these races,
> disable
>     interrupts before enter_idle and make sure that all idle routines do not
>     enable interrupts before entering idle.
> 
> This implies to me that once we have set isidle, if we take an interrupt
> we *have* to drop out of the idle routine.

I don't think that applies anymore; the generic idle loop calls
arch_cpu_idle_enter() before calling arch_cpu_idle() where we would do
the enable.

So in that sense its impossible to get arch_cpu_idle_exit() -- or rather
exit_idle() as called from the interrupts -- to happen before
arch_cpu_idle_enter().

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:55               ` Peter Zijlstra
@ 2014-01-20 11:00                 ` H. Peter Anvin
  2014-01-20 11:05                   ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-20 11:00 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> 
> Ok, so I still don't get the problem of enabling interrupts early.
> 
> If we enable them early we can get interrupts; which afaict fall into
> two groups, those that do and do not set NEED_RESCHED.
> 
> For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> and looped right back into it, so receiving those early -- before
> actually calling MWAIT/HLT seems like a NO-OP.

The description for commit d331e739f5ad seems to indicate otherwise:

    Idle callbacks has some races when enter_idle() sets isidle and
subsequent
    interrupts that can happen on that CPU, before CPU goes to idle. Due
to this,
    an IDLE_END can get called before IDLE_START. To avoid these races,
disable
    interrupts before enter_idle and make sure that all idle routines do not
    enable interrupts before entering idle.

This implies to me that once we have set isidle, if we take an interrupt
we *have* to drop out of the idle routine.

> For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
> places.
> 
>  - current_set_polling_and_test(), we test need_resched after telling
>    remote CPUs they don't need to send interrupts because we're polling
>    for it -- the remote cpus set NEED_RESCHED before testing if we're
>    polling for it.
> 
>  - we test NEED_RESCHED after setting up the monitor and before calling
>    MWAIT. Therefore, if an interrupt would happen right before we call
>    MWAIT, the monitor is already set and the MWAIT does an immediate
>    exit.
> 
> AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.
> 

Well, it is obviously needed for the HLT case.  For MWAIT it seems like
the MONITOR should have gotten disarmed and therefore MWAIT shouldn't
sleep... I don't know off the top of my head if there are any errata in
that department and/or if there are any other issues.

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 10:13     ` Peter Zijlstra
@ 2014-01-20 10:19       ` H. Peter Anvin
  2014-01-20 11:06         ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-20 10:19 UTC (permalink / raw)
  To: Peter Zijlstra, Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
>> Then make them so. The fact was that most of the mwait idle sites
>> were bloody broken. And the single mwait_idle_with_hints() function
>> presents a single nice function that does all the required magics.
> 
> To stress this a bit more; have a look see at mwwait_idle_with_hints();
> it does a whole lot of subtle magic.
> 
>  - current_{set,clr}_polling*(), these are crucial in not missing and
>    wrecking NEED_RESCHED state.
> 
>  - X86_FEATURE_CLFLUSH_MONTIOR quirk
> 
>  - Does the monitor(); if (!need_resched()) mwait() thing.
> 
> All of those are required for a correct and functional idle loop. And
> I've seen sites where any or all of the above were missing/broken.
> 
> Not unifying the lot into a simple usable function is just stupid --
> history has shown people simply cannot be trusted to get this right.
> 

I don't think anyone is arguing that.  The question is rather if the
implementation is correct, and if it is ready for the merge window.

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:30   ` Peter Zijlstra
@ 2014-01-20 10:13     ` Peter Zijlstra
  2014-01-20 10:19       ` H. Peter Anvin
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20 10:13 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> Then make them so. The fact was that most of the mwait idle sites
> were bloody broken. And the single mwait_idle_with_hints() function
> presents a single nice function that does all the required magics.

To stress this a bit more; have a look see at mwwait_idle_with_hints();
it does a whole lot of subtle magic.

 - current_{set,clr}_polling*(), these are crucial in not missing and
   wrecking NEED_RESCHED state.

 - X86_FEATURE_CLFLUSH_MONTIOR quirk

 - Does the monitor(); if (!need_resched()) mwait() thing.

All of those are required for a correct and functional idle loop. And
I've seen sites where any or all of the above were missing/broken.

Not unifying the lot into a simple usable function is just stupid --
history has shown people simply cannot be trusted to get this right.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:23             ` H. Peter Anvin
  2014-01-20  9:29               ` Ingo Molnar
@ 2014-01-20  9:55               ` Peter Zijlstra
  2014-01-20 11:00                 ` H. Peter Anvin
  1 sibling, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20  9:55 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> > 
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> > 
> 
> No, that doesn't work.  The point of __sti_mwait() is that the STI is
> the instruction immediately before the MWAIT, just like the combination
> STI;HLT.  Since the execution of STI is always delayed by one
> instruction, these two instructions form an atomic unit, which means
> interrupts are enabled "after" we have entered MWAIT or HLT.
> 
> > But that's entirely different from saying that core2 doesn't support
> > mwait_idle_with_hints because its a different instruction.
> 
> If you think of STI;MWAIT as a "compound instruction" it kind of is.
> Newer CPUs don't have to play that trick anymore, because there is a
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt
> without having to actually enable interrupts at the point of the MWAIT.

Ok, so I still don't get the problem of enabling interrupts early.

If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not set NEED_RESCHED.

For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
and looped right back into it, so receiving those early -- before
actually calling MWAIT/HLT seems like a NO-OP.

For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
places.

 - current_set_polling_and_test(), we test need_resched after telling
   remote CPUs they don't need to send interrupts because we're polling
   for it -- the remote cpus set NEED_RESCHED before testing if we're
   polling for it.

 - we test NEED_RESCHED after setting up the monitor and before calling
   MWAIT. Therefore, if an interrupt would happen right before we call
   MWAIT, the monitor is already set and the MWAIT does an immediate
   exit.

AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:25                     ` Sedat Dilek
@ 2014-01-20  9:48                       ` Mike Galbraith
  0 siblings, 0 replies; 245+ messages in thread
From: Mike Galbraith @ 2014-01-20  9:48 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, 2014-01-20 at 10:25 +0100, Sedat Dilek wrote:

> It's about the handling of fixes for -next.

Ah, it was a gripe in query form.  My bad.

-Mike

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:23             ` H. Peter Anvin
@ 2014-01-20  9:29               ` Ingo Molnar
  2014-01-20 21:39                 ` Len Brown
  2014-01-20  9:55               ` Peter Zijlstra
  1 sibling, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2014-01-20  9:29 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Peter Zijlstra, Len Brown, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel


* H. Peter Anvin <hpa@zytor.com> wrote:

> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> > 
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> > 
> 
> No, that doesn't work.  The point of __sti_mwait() is that the STI 
> is the instruction immediately before the MWAIT, just like the 
> combination STI;HLT.  Since the execution of STI is always delayed 
> by one instruction, these two instructions form an atomic unit, 
> which means interrupts are enabled "after" we have entered MWAIT or 
> HLT.
> 
> > But that's entirely different from saying that core2 doesn't 
> > support mwait_idle_with_hints because its a different instruction.
> 
> If you think of STI;MWAIT as a "compound instruction" it kind of is. 
> Newer CPUs don't have to play that trick anymore, because there is a 
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt 
> without having to actually enable interrupts at the point of the 
> MWAIT.

As a side note, at minimum the semantic and compatibility difference 
needs to be _very_ clearly present in the naming. Something like 
mwait_old_() or mwait_core2_(). That way such dependencies and 
assumptions don't get lost in code restructuring, etc.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:17                   ` Mike Galbraith
@ 2014-01-20  9:25                     ` Sedat Dilek
  2014-01-20  9:48                       ` Mike Galbraith
  0 siblings, 1 reply; 245+ messages in thread
From: Sedat Dilek @ 2014-01-20  9:25 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 10:17 AM, Mike Galbraith <bitbucket@online.de> wrote:
> On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
>> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>> >>
>> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> >> Q6600 box.  See below for an alternative.
>> >>
>> >> idle: kill unnecessary mwait_idle() resched IPIs
>> >
>> > OK, so despite even further discussion, I have applied this as a merge
>> > fix patch for today.  Let me know when it is all sorted out.
>> >
>>
>> Where is this fix?
>
> If you pull next-20140120, the fix is in it.
>
>> ( Browsing Linux-next remote GIT repository online. )
>> 2x NOPE for me.
>
> Probably because it's a temporary conflict fix.
>

It's about the handling of fixes for -next.
For such kind of "special" tweaks Stephen introduced *next-fixes* (see
his email on linux-next ML and [1]).
Such make-my-system-boot-again and other critical fixes belong there.

BTW, I found the merge hunk (see my other email).

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:16           ` Peter Zijlstra
@ 2014-01-20  9:23             ` H. Peter Anvin
  2014-01-20  9:29               ` Ingo Molnar
  2014-01-20  9:55               ` Peter Zijlstra
  0 siblings, 2 replies; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-20  9:23 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
>>
>> The difference is the STI!
> 
> So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> 

No, that doesn't work.  The point of __sti_mwait() is that the STI is
the instruction immediately before the MWAIT, just like the combination
STI;HLT.  Since the execution of STI is always delayed by one
instruction, these two instructions form an atomic unit, which means
interrupts are enabled "after" we have entered MWAIT or HLT.

> But that's entirely different from saying that core2 doesn't support
> mwait_idle_with_hints because its a different instruction.

If you think of STI;MWAIT as a "compound instruction" it kind of is.
Newer CPUs don't have to play that trick anymore, because there is a
flag to MWAIT which breaks us out of MWAIT on a pending interrupt
without having to actually enable interrupts at the point of the MWAIT.

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:42                 ` Sedat Dilek
  2014-01-20  8:46                   ` Sedat Dilek
@ 2014-01-20  9:17                   ` Mike Galbraith
  2014-01-20  9:25                     ` Sedat Dilek
  1 sibling, 1 reply; 245+ messages in thread
From: Mike Galbraith @ 2014-01-20  9:17 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote: 
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
> >>
> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> >> Q6600 box.  See below for an alternative.
> >>
> >> idle: kill unnecessary mwait_idle() resched IPIs
> >
> > OK, so despite even further discussion, I have applied this as a merge
> > fix patch for today.  Let me know when it is all sorted out.
> >
> 
> Where is this fix?

If you pull next-20140120, the fix is in it.

> ( Browsing Linux-next remote GIT repository online. )
> 2x NOPE for me.

Probably because it's a temporary conflict fix.

-Mike

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:56         ` H. Peter Anvin
@ 2014-01-20  9:16           ` Peter Zijlstra
  2014-01-20  9:23             ` H. Peter Anvin
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20  9:16 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 12:56:47AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> > On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> >> +static void mwait_idle(void)
> >> +{
> >> +       mwait_idle_with_hints(0, 0);
> >> +}
> >> +
> >>
> >> The reason the patch above will crash Core2 machines is because
> >> core2 machines don't support mwait_idle_with_hints().
> >>
> >> The calling sequence for old and new MWAIT instructions is different.
> >> The former must be invoked with interrupts enabled,
> >> and the later can be invoked with interrupts disabled,
> >> which is a feature that Linux takes advantage of.
> > 
> > What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
> > 
> > And your 'old' __sti_mwait(0,0) has the exact same arguments as
> > mwait_idle_with_hints(0,0).
> > 
> 
> The difference is the STI!

So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.

But that's entirely different from saying that core2 doesn't support
mwait_idle_with_hints because its a different instruction.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:26       ` Peter Zijlstra
@ 2014-01-20  8:56         ` H. Peter Anvin
  2014-01-20  9:16           ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-20  8:56 UTC (permalink / raw)
  To: Peter Zijlstra, Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
>> +static void mwait_idle(void)
>> +{
>> +       mwait_idle_with_hints(0, 0);
>> +}
>> +
>>
>> The reason the patch above will crash Core2 machines is because
>> core2 machines don't support mwait_idle_with_hints().
>>
>> The calling sequence for old and new MWAIT instructions is different.
>> The former must be invoked with interrupts enabled,
>> and the later can be invoked with interrupts disabled,
>> which is a feature that Linux takes advantage of.
> 
> What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
> 
> And your 'old' __sti_mwait(0,0) has the exact same arguments as
> mwait_idle_with_hints(0,0).
> 

The difference is the STI!

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:42                 ` Sedat Dilek
@ 2014-01-20  8:46                   ` Sedat Dilek
  2014-01-20 13:10                     ` Stephen Rothwell
  2014-01-20  9:17                   ` Mike Galbraith
  1 sibling, 1 reply; 245+ messages in thread
From: Sedat Dilek @ 2014-01-20  8:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box.  See below for an alternative.
>>>
>>> idle: kill unnecessary mwait_idle() resched IPIs
>>
>> OK, so despite even further discussion, I have applied this as a merge
>> fix patch for today.  Let me know when it is all sorted out.
>>
>
> Where is this fix?
> ( Browsing Linux-next remote GIT repository online. )
> 2x NOPE for me.
>
> - Sedat -
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
> [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
>

Hmmm... Found this in Next/merge.log

+$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
+Applying: idle: kill unnecessary mwait_idle() resched IPIs
+$ git reset HEAD^
+Unstaged changes after reset:
+M arch/x86/include/asm/processor.h
+M arch/x86/kernel/process.c

Is this a local patch not shipped in the Linux-next (remote) GIT repo?
Why is this not in your next-fixes GIT repo?

A bit confused about your -next policies,
- Sedat -

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  3:51               ` Stephen Rothwell
@ 2014-01-20  8:42                 ` Sedat Dilek
  2014-01-20  8:46                   ` Sedat Dilek
  2014-01-20  9:17                   ` Mike Galbraith
  0 siblings, 2 replies; 245+ messages in thread
From: Sedat Dilek @ 2014-01-20  8:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>>
>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> Q6600 box.  See below for an alternative.
>>
>> idle: kill unnecessary mwait_idle() resched IPIs
>
> OK, so despite even further discussion, I have applied this as a merge
> fix patch for today.  Let me know when it is all sorted out.
>

Where is this fix?
( Browsing Linux-next remote GIT repository online. )
2x NOPE for me.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
[2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git

> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  1:00 ` Len Brown
  2014-01-20  1:07   ` H. Peter Anvin
@ 2014-01-20  8:30   ` Peter Zijlstra
  2014-01-20 10:13     ` Peter Zijlstra
  1 sibling, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20  8:30 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Sun, Jan 19, 2014 at 08:00:19PM -0500, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > arch/x86/kernel/process.c: In function 'mwait_idle':
> > /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
> >    __monitor((void *)&current_thread_info()->flags, 0, 0);
> >    ^
> > arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
> >     __sti_mwait(0, 0);
> >     ^
> >
> > Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> > idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> > mwait_idle()") from the idle tree.
> >
> > I am not sure how to fix this so I just reverted the idle tree commit for
> > now (since it reverted cleanly). Please let me know if there is a better
> > solution.
> 
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.

It was part of that other regression fix, the 50+ watt thingy for your
broken EX chips.

It was also written much earlier and widely mailed and published before
you did the core2 thing.

> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...

Then make them so. The fact was that most of the mwait idle sites
were bloody broken. And the single mwait_idle_with_hints() function
presents a single nice function that does all the required magics.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  4:45     ` Len Brown
@ 2014-01-20  8:26       ` Peter Zijlstra
  2014-01-20  8:56         ` H. Peter Anvin
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-20  8:26 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> +static void mwait_idle(void)
> +{
> +       mwait_idle_with_hints(0, 0);
> +}
> +
> 
> The reason the patch above will crash Core2 machines is because
> core2 machines don't support mwait_idle_with_hints().
> 
> The calling sequence for old and new MWAIT instructions is different.
> The former must be invoked with interrupts enabled,
> and the later can be invoked with interrupts disabled,
> which is a feature that Linux takes advantage of.

What old and new? They're the same byte sequence: 0x0f 0x01 0xc9

And your 'old' __sti_mwait(0,0) has the exact same arguments as
mwait_idle_with_hints(0,0).

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 22:25     ` Peter Zijlstra
@ 2014-01-20  4:45     ` Len Brown
  2014-01-20  8:26       ` Peter Zijlstra
  1 sibling, 1 reply; 245+ messages in thread
From: Len Brown @ 2014-01-20  4:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

+static void mwait_idle(void)
+{
+       mwait_idle_with_hints(0, 0);
+}
+

The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().

The calling sequence for old and new MWAIT instructions is different.
The former must be invoked with interrupts enabled,
and the later can be invoked with interrupts disabled,
which is a feature that Linux takes advantage of.

thanks,
-Len

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18  9:46             ` Mike Galbraith
  2014-01-18 12:44               ` Peter Zijlstra
@ 2014-01-20  3:51               ` Stephen Rothwell
  2014-01-20  8:42                 ` Sedat Dilek
  1 sibling, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-20  3:51 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: H. Peter Anvin, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box.  See below for an alternative.
> 
> idle: kill unnecessary mwait_idle() resched IPIs

OK, so despite even further discussion, I have applied this as a merge
fix patch for today.  Let me know when it is all sorted out.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  1:00 ` Len Brown
@ 2014-01-20  1:07   ` H. Peter Anvin
  2014-01-20  8:30   ` Peter Zijlstra
  1 sibling, 0 replies; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-20  1:07 UTC (permalink / raw)
  To: Len Brown, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel

On 01/19/2014 05:00 PM, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> arch/x86/kernel/process.c: In function 'mwait_idle':
>> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>>    ^
>> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>>     __sti_mwait(0, 0);
>>     ^
>>
>> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
>> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
>> mwait_idle()") from the idle tree.
>>
>> I am not sure how to fix this so I just reverted the idle tree commit for
>> now (since it reverted cleanly). Please let me know if there is a better
>> solution.
> 
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.
> 
> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...
> 

Sounds like a NAK to me, in which case that bit should probably be
deferred and reintroduced after fixing via the idle tree?

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16  3:58 Stephen Rothwell
  2014-01-16 12:19 ` Peter Zijlstra
@ 2014-01-20  1:00 ` Len Brown
  2014-01-20  1:07   ` H. Peter Anvin
  2014-01-20  8:30   ` Peter Zijlstra
  1 sibling, 2 replies; 245+ messages in thread
From: Len Brown @ 2014-01-20  1:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>    ^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>     __sti_mwait(0, 0);
>     ^
>
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
>
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.

IMO, a regression fix (restore mwait_idle()) is more important than a clean up
(restructure mwait routines), and the clean-up should take a back seat;
in -tip, in -next, upstream, and in -stable.

Also, I'm wondering if that clean-up went too far -- as not all users of mwait
are necessarily under the same conditions...

thanks,
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 19:14                   ` H. Peter Anvin
@ 2014-01-18 21:54                     ` Peter Zijlstra
  0 siblings, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-18 21:54 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Mike Galbraith, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote:
> >> Could something like this work?
> >>
> >> 	local_irq_enable();
> >> 	mwait_idle_with_hints(0,0);
> >>

> This means an interrupt window is open and we can take an interrupt
> between checking need_resched and the MWAIT, which couldn't happen with
> __sti_mwait().
> 
> Are we sure that is actually safe?

current_set_polling_and_test() vs resched_task() should be good that
way, but I've got a terrible head-ache today so don't rely on anything
much I say.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 15:21                 ` Mike Galbraith
@ 2014-01-18 19:14                   ` H. Peter Anvin
  2014-01-18 21:54                     ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-18 19:14 UTC (permalink / raw)
  To: Mike Galbraith, Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Len Brown,
	linux-next, linux-kernel

On 01/18/2014 07:21 AM, Mike Galbraith wrote:
> On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: 
>> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box.  See below for an alternative.
>>
>> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
>> disabled.
>>
>> Could something like this work?
>>
>> 	local_irq_enable();
>> 	mwait_idle_with_hints(0,0);
>>
>> The interrupt enable window is slightly larger, but I'm not immediately
>> seeing a problem with that.
> 
> Yup, works just fine.  Less is more.
> 
> Nice to see a _progression_ in the pipe too btw.
> 

This means an interrupt window is open and we can take an interrupt
between checking need_resched and the MWAIT, which couldn't happen with
__sti_mwait().

Are we sure that is actually safe?

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 12:44               ` Peter Zijlstra
  2014-01-18 14:06                 ` Sabrina Dubroca
@ 2014-01-18 15:21                 ` Mike Galbraith
  2014-01-18 19:14                   ` H. Peter Anvin
  1 sibling, 1 reply; 245+ messages in thread
From: Mike Galbraith @ 2014-01-18 15:21 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: 
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> > 
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box.  See below for an alternative.
> 
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
> 
> Could something like this work?
> 
> 	local_irq_enable();
> 	mwait_idle_with_hints(0,0);
> 
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.

Yup, works just fine.  Less is more.

Nice to see a _progression_ in the pipe too btw.

-Mike

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 12:44               ` Peter Zijlstra
@ 2014-01-18 14:06                 ` Sabrina Dubroca
  2014-01-18 15:21                 ` Mike Galbraith
  1 sibling, 0 replies; 245+ messages in thread
From: Sabrina Dubroca @ 2014-01-18 14:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Mike Galbraith, Stephen Rothwell, H. Peter Anvin,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next,
	linux-kernel

2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> > 
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box.  See below for an alternative.
> 
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
> 
> Could something like this work?
> 
> 	local_irq_enable();
> 	mwait_idle_with_hints(0,0);
> 
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.

next-20140117 doesn't boot on my T7300 laptop either. I've tried the
two fixes, they both work for me.


Thanks,

-- 
Sabrina

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18  9:46             ` Mike Galbraith
@ 2014-01-18 12:44               ` Peter Zijlstra
  2014-01-18 14:06                 ` Sabrina Dubroca
  2014-01-18 15:21                 ` Mike Galbraith
  2014-01-20  3:51               ` Stephen Rothwell
  1 sibling, 2 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-18 12:44 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Stephen Rothwell, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> 
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box.  See below for an alternative.

Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
disabled.

Could something like this work?

	local_irq_enable();
	mwait_idle_with_hints(0,0);

The interrupt enable window is slightly larger, but I'm not immediately
seeing a problem with that.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-17  3:45           ` Stephen Rothwell
@ 2014-01-18  9:46             ` Mike Galbraith
  2014-01-18 12:44               ` Peter Zijlstra
  2014-01-20  3:51               ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Mike Galbraith @ 2014-01-18  9:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: H. Peter Anvin, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Fri, 2014-01-17 at 14:45 +1100, Stephen Rothwell wrote: 
> Hi all,
> 
> On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > > 
> > > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > > <peterz@infradead.org> wrote:
> > >> 
> > >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> > >> wrote:
> > >>> 
> > >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> > >>> <peterz@infradead.org> wrote:
> > >>>> 
> > >>>> I think the below ought to work
> > >>> 
> > >>> To be clear, all you did was replace the body of mwait_idle()
> > >>> with
> > >>> 
> > >>> mwait_idle_with_hints(0, 0);
> > >> 
> > >> Pretty much, and add the asm/mwait.h include, otherwise you'll
> > >> end up with a compile fail.
> > >> 
> > >>> (and the comment above it)?  I need to apply in incremental
> > >>> patch in the merge commit.
> > >> 
> > >> I don't think I touched the comment at all.
> > > 
> > 
> > In retrospect this bit probably should have gone through the idle
> > tree.  That was my bad, I need to coordinate with Len better.
> 
> So this is what I added as a merge fix patch.  Someone just needs to make
> sure Linus gets this when the latter of the tow trees gets merged.

I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box.  See below for an alternative.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Jan 2014 14:42:06 +1100
> Subject: [PATCH] x86 idle: mwait_idle merge update
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/process.c | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index db471a87fdd8..4da840f01561 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -28,6 +28,7 @@
>  #include <asm/fpu-internal.h>
>  #include <asm/debugreg.h>
>  #include <asm/nmi.h>
> +#include <asm/mwait.h>
>  
>  /*
>   * per-CPU TSS segments. Threads are completely 'soft' on Linux,
> @@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
>  
>  static void mwait_idle(void)
>  {
> -	if (!need_resched()) {
> -		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
> -			clflush((void *)&current_thread_info()->flags);
> -
> -		__monitor((void *)&current_thread_info()->flags, 0, 0);
> -		smp_mb();
> -		if (!need_resched())
> -			__sti_mwait(0, 0);
> -		else
> -			local_irq_enable();
> -	} else
> -		local_irq_enable();
> +	mwait_idle_with_hints(0, 0);
>  }
>  
>  void select_idle_routine(const struct cpuinfo_x86 *c)
> -- 
> 1.8.5.2

idle: kill unnecessary mwait_idle() resched IPIs

Set/clear polling instead.

Q6600, pipe-test scheduling cross core:
3.8.13                   487.2 KHz    1.000
3.13.0-master            415.5 KHz     .852
3.13.0-master+           415.2 KHz     .852     + restore mwait_idle
3.13.0-master++          488.5 KHz    1.002     + restore mwait_idle + IPI fix
3.13.0-next-20140117     -ENOBOOT
3.13.0-next-20140117+    531.4 KHz    1.090     + IPI fix

Signed-off-by: Mike Galbraith <bitbucket@online.de>
---
 arch/x86/include/asm/processor.h |    8 ++++++++
 arch/x86/kernel/process.c        |   10 +++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -723,6 +723,14 @@ static inline void sync_core(void)
 #endif
 }
 
+static inline void __sti_mwait(unsigned long eax, unsigned long ecx)
+{
+	trace_hardirqs_on();
+	/* "mwait %eax, %ecx;" */
+	asm volatile("sti; .byte 0x0f, 0x01, 0xc9;"
+		     :: "a" (eax), "c" (ecx));
+}
+
 extern void select_idle_routine(const struct cpuinfo_x86 *c);
 extern void init_amd_e400_c1e_mask(void);
 
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -427,18 +428,21 @@ static int prefer_mwait_c1_over_halt(con
 
 static void mwait_idle(void)
 {
-	if (!need_resched()) {
-		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+	if (!current_set_polling_and_test()) {
+		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+			mb();
 			clflush((void *)&current_thread_info()->flags);
+			mb();
+		}
 
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
-		smp_mb();
 		if (!need_resched())
 			__sti_mwait(0, 0);
 		else
 			local_irq_enable();
 	} else
 		local_irq_enable();
+	current_clr_polling();
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:51         ` H. Peter Anvin
@ 2014-01-17  3:45           ` Stephen Rothwell
  2014-01-18  9:46             ` Mike Galbraith
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-17  3:45 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

Hi all,

On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > <peterz@infradead.org> wrote:
> >> 
> >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> >> wrote:
> >>> 
> >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> >>> <peterz@infradead.org> wrote:
> >>>> 
> >>>> I think the below ought to work
> >>> 
> >>> To be clear, all you did was replace the body of mwait_idle()
> >>> with
> >>> 
> >>> mwait_idle_with_hints(0, 0);
> >> 
> >> Pretty much, and add the asm/mwait.h include, otherwise you'll
> >> end up with a compile fail.
> >> 
> >>> (and the comment above it)?  I need to apply in incremental
> >>> patch in the merge commit.
> >> 
> >> I don't think I touched the comment at all.
> > 
> 
> In retrospect this bit probably should have gone through the idle
> tree.  That was my bad, I need to coordinate with Len better.

So this is what I added as a merge fix patch.  Someone just needs to make
sure Linus gets this when the latter of the tow trees gets merged.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Jan 2014 14:42:06 +1100
Subject: [PATCH] x86 idle: mwait_idle merge update

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/process.c | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index db471a87fdd8..4da840f01561 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
 
 static void mwait_idle(void)
 {
-	if (!need_resched()) {
-		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
-			clflush((void *)&current_thread_info()->flags);
-
-		__monitor((void *)&current_thread_info()->flags, 0, 0);
-		smp_mb();
-		if (!need_resched())
-			__sti_mwait(0, 0);
-		else
-			local_irq_enable();
-	} else
-		local_irq_enable();
+	mwait_idle_with_hints(0, 0);
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)
-- 
1.8.5.2


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:34       ` Stephen Rothwell
@ 2014-01-16 22:51         ` H. Peter Anvin
  2014-01-17  3:45           ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-16 22:51 UTC (permalink / raw)
  To: Stephen Rothwell, Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, linux-kernel

On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> <peterz@infradead.org> wrote:
>> 
>> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
>> wrote:
>>> 
>>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
>>> <peterz@infradead.org> wrote:
>>>> 
>>>> I think the below ought to work
>>> 
>>> To be clear, all you did was replace the body of mwait_idle()
>>> with
>>> 
>>> mwait_idle_with_hints(0, 0);
>> 
>> Pretty much, and add the asm/mwait.h include, otherwise you'll
>> end up with a compile fail.
>> 
>>> (and the comment above it)?  I need to apply in incremental
>>> patch in the merge commit.
>> 
>> I don't think I touched the comment at all.
> 

In retrospect this bit probably should have gone through the idle
tree.  That was my bad, I need to coordinate with Len better.

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:25     ` Peter Zijlstra
@ 2014-01-16 22:34       ` Stephen Rothwell
  2014-01-16 22:51         ` H. Peter Anvin
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-16 22:34 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Hi Peter,

On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > I think the below ought to work
> > 
> > To be clear, all you did was replace the body of mwait_idle() with
> > 
> > 	mwait_idle_with_hints(0, 0);
> 
> Pretty much, and add the asm/mwait.h include, otherwise you'll end up
> with a compile fail.
> 
> > (and the comment above it)?  I need to apply in incremental patch in the
> > merge commit.
> 
> I don't think I touched the comment at all.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 20:46   ` Stephen Rothwell
@ 2014-01-16 22:25     ` Peter Zijlstra
  2014-01-16 22:34       ` Stephen Rothwell
  2014-01-20  4:45     ` Len Brown
  1 sibling, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-16 22:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > I think the below ought to work
> 
> To be clear, all you did was replace the body of mwait_idle() with
> 
> 	mwait_idle_with_hints(0, 0);

Pretty much, and add the asm/mwait.h include, otherwise you'll end up
with a compile fail.

> (and the comment above it)?  I need to apply in incremental patch in the
> merge commit.

I don't think I touched the comment at all.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 12:19 ` Peter Zijlstra
  2014-01-16 20:46   ` Stephen Rothwell
@ 2014-01-16 20:56   ` H. Peter Anvin
  1 sibling, 0 replies; 245+ messages in thread
From: H. Peter Anvin @ 2014-01-16 20:56 UTC (permalink / raw)
  To: Peter Zijlstra, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, linux-kernel

On 01/16/2014 04:19 AM, Peter Zijlstra wrote:
> + * MONITOR/MWAIT with no hints, used for default default C1 state.

The default default?

	-hpa

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 12:19 ` Peter Zijlstra
@ 2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 22:25     ` Peter Zijlstra
  2014-01-20  4:45     ` Len Brown
  2014-01-16 20:56   ` H. Peter Anvin
  1 sibling, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-16 20:46 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Hi Peter,

On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> I think the below ought to work

To be clear, all you did was replace the body of mwait_idle() with

	mwait_idle_with_hints(0, 0);

(and the comment above it)?  I need to apply in incremental patch in the
merge commit.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16  3:58 Stephen Rothwell
@ 2014-01-16 12:19 ` Peter Zijlstra
  2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 20:56   ` H. Peter Anvin
  2014-01-20  1:00 ` Len Brown
  1 sibling, 2 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-16 12:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

On Thu, Jan 16, 2014 at 02:58:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>    ^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>     __sti_mwait(0, 0);
>     ^
> 
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
> 
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.

I think the below ought to work

---
 arch/x86/kernel/process.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8b5..220df9b2f22a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -398,6 +399,37 @@ static void amd_e400_idle(void)
 		default_idle();
 }
 
+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *  
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+	if (c->x86_vendor != X86_VENDOR_INTEL)
+		return 0;
+
+	if (!cpu_has(c, X86_FEATURE_MWAIT))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+static void mwait_idle(void)
+{
+	mwait_idle_with_hints(0, 0);
+}
+
 void select_idle_routine(const struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
@@ -411,6 +443,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c)
 		/* E400: APIC timer interrupt does not wake up CPU from C1e */
 		pr_info("using AMD E400 aware idle routine\n");
 		x86_idle = amd_e400_idle;
+	} else if (prefer_mwait_c1_over_halt(c)) {
+		pr_info("using mwait in idle threads\n");
+		x86_idle = mwait_idle;
 	} else
 		x86_idle = default_idle;
 }

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:43       ` Mikulas Patocka
  2014-01-14 22:03         ` Rafael J. Wysocki
@ 2014-01-16 12:14         ` Peter Zijlstra
  1 sibling, 0 replies; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-16 12:14 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, Viresh Kumar, linux-next, linux-kernel,
	cpufreq

On Tue, Jan 14, 2014 at 04:43:43PM -0500, Mikulas Patocka wrote:
> > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> >  		if (retry) {
> >  			pr_debug("retry %u, previous result %u, waiting...\n",
> >  					retry, result);
> > +			local_irq_restore(flags);
> 
> ^^^ this is wrong, because the function speedstep_set_state may already be 
> called with interrupts disabled from speedstep_get_freqs. So, you need to 
> enable interrupts unconditionally, even if they were disabled at the 
> beginning of the function speedstep_set_state.
> 
> I know it's dirty to enable interrupts in a function that was called with 
> disabled interrupts, but here it must be so (you could rewrite 
> speedstep_get_freqs to not disable interrupts if you want to avoid this 
> dirtiness).

Egads; I think you had better, this is vile beyond reason.

> >  			mdelay(retry * 50);
> > +			local_irq_save(flags);
> >  		}
> >  		retry++;
> >  		__asm__ __volatile__(
> > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> >  
> >  	/* enable IRQs */
> >  	local_irq_restore(flags);
> > +	preempt_enable();
> >  
> >  	if (new_state == state)
> >  		pr_debug("change to %u MHz succeeded after %u tries "
> 
> You need also preempt_disable/enable in speedstep_get_freqs.

Argh I see, this is really horrid.


Anyway, its Rafael's call, its his subsystem he gets to fix it when it
explodes.

/me shudders

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-01-16  3:58 Stephen Rothwell
  2014-01-16 12:19 ` Peter Zijlstra
  2014-01-20  1:00 ` Len Brown
  0 siblings, 2 replies; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-16  3:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Len Brown
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kernel/process.c: In function 'mwait_idle':
/scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
   __monitor((void *)&current_thread_info()->flags, 0, 0);
   ^
arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
    __sti_mwait(0, 0);
    ^

Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
mwait_idle()") from the idle tree.

I am not sure how to fix this so I just reverted the idle tree commit for
now (since it reverted cleanly). Please let me know if there is a better
solution.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:52           ` Mikulas Patocka
@ 2014-01-14 22:18             ` Rafael J. Wysocki
  0 siblings, 0 replies; 245+ messages in thread
From: Rafael J. Wysocki @ 2014-01-14 22:18 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq

On Tuesday, January 14, 2014 04:52:20 PM Mikulas Patocka wrote:
> 
> On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:
> 
> > On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> > > 
> > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > 
> > > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > > preempt_enable_no_resched() from modules")
> > > > 
> > > > Read these two lines, then note that:
> > > > 
> > > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > > > 
> > > > this obviously will not work as preempt_check_resched() and
> > > > preempt_enable_no_resched() are no longer available to modules.
> > > 
> > > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> > > linux-next, that broke my patch.
> > > 
> > > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > > patch is a very good idea.
> > > > > > 
> > > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > > interrupt is required for progress, and how does it make the progress
> > > > > > happen.
> > > > > 
> > > > > There is no explanation. It's hardware issue and I have no documentation 
> > > > > for the hardware.
> > > > 
> > > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > > hardware does/needs.
> > > > 
> > > > > The general problem is that if there are bus-master transfers running (or 
> > > > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > > > You can wait a little bit and retry and maybe you succeed changing the 
> > > > > frequency next time.
> > > > > 
> > > > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > > > matter how long do you wait. I found it experimentally, I don't know 
> > > > > reason for that.
> > > > 
> > > > Sounds like magic goo..
> > > > 
> > > > In any case, try the below, it does the same but is far less horrid.
> > > > 
> > > > ---
> > > >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > > index 0f5326d6f79f..57d31538c248 100644
> > > > --- a/drivers/cpufreq/speedstep-smi.c
> > > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > > >  		return;
> > > >  
> > > >  	/* Disable IRQs */
> > > > +	preempt_disable();
> > > >  	local_irq_save(flags);
> > > >  
> > > >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > > >  		if (retry) {
> > > >  			pr_debug("retry %u, previous result %u, waiting...\n",
> > > >  					retry, result);
> > > > +			local_irq_restore(flags);
> > > 
> > > ^^^ this is wrong, because the function speedstep_set_state may already be 
> > > called with interrupts disabled from speedstep_get_freqs. So, you need to 
> > > enable interrupts unconditionally, even if they were disabled at the 
> > > beginning of the function speedstep_set_state.
> > > 
> > > I know it's dirty to enable interrupts in a function that was called with 
> > > disabled interrupts, but here it must be so (you could rewrite 
> > > speedstep_get_freqs to not disable interrupts if you want to avoid this 
> > > dirtiness).
> > > 
> > > >  			mdelay(retry * 50);
> > > > +			local_irq_save(flags);
> > > >  		}
> > > >  		retry++;
> > > >  		__asm__ __volatile__(
> > > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > > >  
> > > >  	/* enable IRQs */
> > > >  	local_irq_restore(flags);
> > > > +	preempt_enable();
> > > >  
> > > >  	if (new_state == state)
> > > >  		pr_debug("change to %u MHz succeeded after %u tries "
> > > 
> > > You need also preempt_disable/enable in speedstep_get_freqs.
> > > 
> > > 
> > > Here I'm resending the patch, to account for 
> > > 62b94a08da1bae9d187d49dfcd6665af393750f8.
> > 
> > Do I think correctly that this should work regardless of whether or not
> > 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?
> 
> Yes.

OK

I'll replace your original patch with this version, then.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:43       ` Mikulas Patocka
@ 2014-01-14 22:03         ` Rafael J. Wysocki
  2014-01-14 21:52           ` Mikulas Patocka
  2014-01-16 12:14         ` Peter Zijlstra
  1 sibling, 1 reply; 245+ messages in thread
From: Rafael J. Wysocki @ 2014-01-14 22:03 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq

On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> 
> On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> 
> > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > preempt_enable_no_resched() from modules")
> > 
> > Read these two lines, then note that:
> > 
> > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > 
> > this obviously will not work as preempt_check_resched() and
> > preempt_enable_no_resched() are no longer available to modules.
> 
> I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> linux-next, that broke my patch.
> 
> > > > I think that pm commit is a very good example of why the sched/preempt
> > > > patch is a very good idea.
> > > > 
> > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > interrupt is required for progress, and how does it make the progress
> > > > happen.
> > > 
> > > There is no explanation. It's hardware issue and I have no documentation 
> > > for the hardware.
> > 
> > Rafael works for Intel, he ought to be able to figure out wtf the
> > hardware does/needs.
> > 
> > > The general problem is that if there are bus-master transfers running (or 
> > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > You can wait a little bit and retry and maybe you succeed changing the 
> > > frequency next time.
> > > 
> > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > matter how long do you wait. I found it experimentally, I don't know 
> > > reason for that.
> > 
> > Sounds like magic goo..
> > 
> > In any case, try the below, it does the same but is far less horrid.
> > 
> > ---
> >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > index 0f5326d6f79f..57d31538c248 100644
> > --- a/drivers/cpufreq/speedstep-smi.c
> > +++ b/drivers/cpufreq/speedstep-smi.c
> > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> >  		return;
> >  
> >  	/* Disable IRQs */
> > +	preempt_disable();
> >  	local_irq_save(flags);
> >  
> >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> >  		if (retry) {
> >  			pr_debug("retry %u, previous result %u, waiting...\n",
> >  					retry, result);
> > +			local_irq_restore(flags);
> 
> ^^^ this is wrong, because the function speedstep_set_state may already be 
> called with interrupts disabled from speedstep_get_freqs. So, you need to 
> enable interrupts unconditionally, even if they were disabled at the 
> beginning of the function speedstep_set_state.
> 
> I know it's dirty to enable interrupts in a function that was called with 
> disabled interrupts, but here it must be so (you could rewrite 
> speedstep_get_freqs to not disable interrupts if you want to avoid this 
> dirtiness).
> 
> >  			mdelay(retry * 50);
> > +			local_irq_save(flags);
> >  		}
> >  		retry++;
> >  		__asm__ __volatile__(
> > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> >  
> >  	/* enable IRQs */
> >  	local_irq_restore(flags);
> > +	preempt_enable();
> >  
> >  	if (new_state == state)
> >  		pr_debug("change to %u MHz succeeded after %u tries "
> 
> You need also preempt_disable/enable in speedstep_get_freqs.
> 
> 
> Here I'm resending the patch, to account for 
> 62b94a08da1bae9d187d49dfcd6665af393750f8.

Do I think correctly that this should work regardless of whether or not
62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?

> From: Mikulas Patocka <mpatocka@redhat.com>
> 
> speedstep-smi: enable interrupts when waiting
> 
> On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
> speedstep-smi driver sometimes loads and sometimes doesn't load with
> "change to state X failed" message.
> 
> I found out that we need to enable interrupts while waiting. When we
> enable interrupts, the blockage that prevents frequency transition
> resolves and the transition is possible. With disabled interrupts, the
> blockage doesn't resolve (no matter how long do we wait).
> 
> This patch enables interrupts in the function speedstep_set_state that can
> be called with disabled interrupts. However, this function is called with
> disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
> any problem.
> 
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> 
> ---
>  drivers/cpufreq/speedstep-lib.c |    3 +++
>  drivers/cpufreq/speedstep-smi.c |   12 ++++++++++++
>  2 files changed, 15 insertions(+)
> 
> Index: linux-next/drivers/cpufreq/speedstep-smi.c
> ===================================================================
> --- linux-next.orig/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:26:59.000000000 +0100
> +++ linux-next/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:35:11.000000000 +0100
> @@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned
>  		return;
>  
>  	/* Disable IRQs */
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> @@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned
>  
>  	do {
>  		if (retry) {
> +			/*
> +			 * We need to enable interrupts, otherwise the blockage
> +			 * won't resolve.
> +			 *
> +			 * We disable preemption so that other processes don't
> +			 * run. If other processes were running, they could
> +			 * submit more DMA requests, making the blockage worse.
> +			 */
>  			pr_debug("retry %u, previous result %u, waiting...\n",
>  					retry, result);
> +			local_irq_enable();
>  			mdelay(retry * 50);
> +			local_irq_disable();
>  		}
>  		retry++;
>  		__asm__ __volatile__(
> @@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned
>  
>  	/* enable IRQs */
>  	local_irq_restore(flags);
> +	preempt_enable();
>  
>  	if (new_state == state)
>  		pr_debug("change to %u MHz succeeded after %u tries "
> Index: linux-next/drivers/cpufreq/speedstep-lib.c
> ===================================================================
> --- linux-next.orig/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:29:07.000000000 +0100
> +++ linux-next/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:31:04.000000000 +0100
> @@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp
>  
>  	pr_debug("previous speed is %u\n", prev_speed);
>  
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	/* switch to low state */
> @@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp
>  
>  out:
>  	local_irq_restore(flags);
> +	preempt_enable();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(speedstep_get_freqs);
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 22:03         ` Rafael J. Wysocki
@ 2014-01-14 21:52           ` Mikulas Patocka
  2014-01-14 22:18             ` Rafael J. Wysocki
  0 siblings, 1 reply; 245+ messages in thread
From: Mikulas Patocka @ 2014-01-14 21:52 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq



On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:

> On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> > 
> > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > 
> > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > preempt_enable_no_resched() from modules")
> > > 
> > > Read these two lines, then note that:
> > > 
> > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > > 
> > > this obviously will not work as preempt_check_resched() and
> > > preempt_enable_no_resched() are no longer available to modules.
> > 
> > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> > linux-next, that broke my patch.
> > 
> > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > patch is a very good idea.
> > > > > 
> > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > interrupt is required for progress, and how does it make the progress
> > > > > happen.
> > > > 
> > > > There is no explanation. It's hardware issue and I have no documentation 
> > > > for the hardware.
> > > 
> > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > hardware does/needs.
> > > 
> > > > The general problem is that if there are bus-master transfers running (or 
> > > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > > You can wait a little bit and retry and maybe you succeed changing the 
> > > > frequency next time.
> > > > 
> > > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > > matter how long do you wait. I found it experimentally, I don't know 
> > > > reason for that.
> > > 
> > > Sounds like magic goo..
> > > 
> > > In any case, try the below, it does the same but is far less horrid.
> > > 
> > > ---
> > >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > index 0f5326d6f79f..57d31538c248 100644
> > > --- a/drivers/cpufreq/speedstep-smi.c
> > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > >  		return;
> > >  
> > >  	/* Disable IRQs */
> > > +	preempt_disable();
> > >  	local_irq_save(flags);
> > >  
> > >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > >  		if (retry) {
> > >  			pr_debug("retry %u, previous result %u, waiting...\n",
> > >  					retry, result);
> > > +			local_irq_restore(flags);
> > 
> > ^^^ this is wrong, because the function speedstep_set_state may already be 
> > called with interrupts disabled from speedstep_get_freqs. So, you need to 
> > enable interrupts unconditionally, even if they were disabled at the 
> > beginning of the function speedstep_set_state.
> > 
> > I know it's dirty to enable interrupts in a function that was called with 
> > disabled interrupts, but here it must be so (you could rewrite 
> > speedstep_get_freqs to not disable interrupts if you want to avoid this 
> > dirtiness).
> > 
> > >  			mdelay(retry * 50);
> > > +			local_irq_save(flags);
> > >  		}
> > >  		retry++;
> > >  		__asm__ __volatile__(
> > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > >  
> > >  	/* enable IRQs */
> > >  	local_irq_restore(flags);
> > > +	preempt_enable();
> > >  
> > >  	if (new_state == state)
> > >  		pr_debug("change to %u MHz succeeded after %u tries "
> > 
> > You need also preempt_disable/enable in speedstep_get_freqs.
> > 
> > 
> > Here I'm resending the patch, to account for 
> > 62b94a08da1bae9d187d49dfcd6665af393750f8.
> 
> Do I think correctly that this should work regardless of whether or not
> 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?

Yes.

Mikulas

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 20:05     ` Peter Zijlstra
@ 2014-01-14 21:43       ` Mikulas Patocka
  2014-01-14 22:03         ` Rafael J. Wysocki
  2014-01-16 12:14         ` Peter Zijlstra
  0 siblings, 2 replies; 245+ messages in thread
From: Mikulas Patocka @ 2014-01-14 21:43 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, Viresh Kumar, linux-next, linux-kernel,
	cpufreq



On Tue, 14 Jan 2014, Peter Zijlstra wrote:

> On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > preempt_enable_no_resched() from modules")
> 
> Read these two lines, then note that:
> 
> > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> 
> this obviously will not work as preempt_check_resched() and
> preempt_enable_no_resched() are no longer available to modules.

I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
linux-next, that broke my patch.

> > > I think that pm commit is a very good example of why the sched/preempt
> > > patch is a very good idea.
> > > 
> > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > interrupt is required for progress, and how does it make the progress
> > > happen.
> > 
> > There is no explanation. It's hardware issue and I have no documentation 
> > for the hardware.
> 
> Rafael works for Intel, he ought to be able to figure out wtf the
> hardware does/needs.
> 
> > The general problem is that if there are bus-master transfers running (or 
> > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > You can wait a little bit and retry and maybe you succeed changing the 
> > frequency next time.
> > 
> > If you enable interrupts, wait, disable interrupts and retry, you may 
> > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > matter how long do you wait. I found it experimentally, I don't know 
> > reason for that.
> 
> Sounds like magic goo..
> 
> In any case, try the below, it does the same but is far less horrid.
> 
> ---
>  drivers/cpufreq/speedstep-smi.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> index 0f5326d6f79f..57d31538c248 100644
> --- a/drivers/cpufreq/speedstep-smi.c
> +++ b/drivers/cpufreq/speedstep-smi.c
> @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
>  		return;
>  
>  	/* Disable IRQs */
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
>  		if (retry) {
>  			pr_debug("retry %u, previous result %u, waiting...\n",
>  					retry, result);
> +			local_irq_restore(flags);

^^^ this is wrong, because the function speedstep_set_state may already be 
called with interrupts disabled from speedstep_get_freqs. So, you need to 
enable interrupts unconditionally, even if they were disabled at the 
beginning of the function speedstep_set_state.

I know it's dirty to enable interrupts in a function that was called with 
disabled interrupts, but here it must be so (you could rewrite 
speedstep_get_freqs to not disable interrupts if you want to avoid this 
dirtiness).

>  			mdelay(retry * 50);
> +			local_irq_save(flags);
>  		}
>  		retry++;
>  		__asm__ __volatile__(
> @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
>  
>  	/* enable IRQs */
>  	local_irq_restore(flags);
> +	preempt_enable();
>  
>  	if (new_state == state)
>  		pr_debug("change to %u MHz succeeded after %u tries "

You need also preempt_disable/enable in speedstep_get_freqs.


Here I'm resending the patch, to account for 
62b94a08da1bae9d187d49dfcd6665af393750f8.



From: Mikulas Patocka <mpatocka@redhat.com>

speedstep-smi: enable interrupts when waiting

On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
speedstep-smi driver sometimes loads and sometimes doesn't load with
"change to state X failed" message.

I found out that we need to enable interrupts while waiting. When we
enable interrupts, the blockage that prevents frequency transition
resolves and the transition is possible. With disabled interrupts, the
blockage doesn't resolve (no matter how long do we wait).

This patch enables interrupts in the function speedstep_set_state that can
be called with disabled interrupts. However, this function is called with
disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
any problem.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 drivers/cpufreq/speedstep-lib.c |    3 +++
 drivers/cpufreq/speedstep-smi.c |   12 ++++++++++++
 2 files changed, 15 insertions(+)

Index: linux-next/drivers/cpufreq/speedstep-smi.c
===================================================================
--- linux-next.orig/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:26:59.000000000 +0100
+++ linux-next/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:35:11.000000000 +0100
@@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned
 		return;
 
 	/* Disable IRQs */
+	preempt_disable();
 	local_irq_save(flags);
 
 	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
@@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned
 
 	do {
 		if (retry) {
+			/*
+			 * We need to enable interrupts, otherwise the blockage
+			 * won't resolve.
+			 *
+			 * We disable preemption so that other processes don't
+			 * run. If other processes were running, they could
+			 * submit more DMA requests, making the blockage worse.
+			 */
 			pr_debug("retry %u, previous result %u, waiting...\n",
 					retry, result);
+			local_irq_enable();
 			mdelay(retry * 50);
+			local_irq_disable();
 		}
 		retry++;
 		__asm__ __volatile__(
@@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned
 
 	/* enable IRQs */
 	local_irq_restore(flags);
+	preempt_enable();
 
 	if (new_state == state)
 		pr_debug("change to %u MHz succeeded after %u tries "
Index: linux-next/drivers/cpufreq/speedstep-lib.c
===================================================================
--- linux-next.orig/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:29:07.000000000 +0100
+++ linux-next/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:31:04.000000000 +0100
@@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp
 
 	pr_debug("previous speed is %u\n", prev_speed);
 
+	preempt_disable();
 	local_irq_save(flags);
 
 	/* switch to low state */
@@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp
 
 out:
 	local_irq_restore(flags);
+	preempt_enable();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 19:06   ` Mikulas Patocka
@ 2014-01-14 20:05     ` Peter Zijlstra
  2014-01-14 21:43       ` Mikulas Patocka
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-14 20:05 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, linux-next, linux-kernel

On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > preempt_enable_no_resched() from modules")

Read these two lines, then note that:

> Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?

this obviously will not work as preempt_check_resched() and
preempt_enable_no_resched() are no longer available to modules.

> > I think that pm commit is a very good example of why the sched/preempt
> > patch is a very good idea.
> > 
> > Also that Changelog fails to explain why enabling interrupts helps. What
> > interrupt is required for progress, and how does it make the progress
> > happen.
> 
> There is no explanation. It's hardware issue and I have no documentation 
> for the hardware.

Rafael works for Intel, he ought to be able to figure out wtf the
hardware does/needs.

> The general problem is that if there are bus-master transfers running (or 
> possibly for other hardware reasons), the CPU refuses to change frequency. 
> You can wait a little bit and retry and maybe you succeed changing the 
> frequency next time.
> 
> If you enable interrupts, wait, disable interrupts and retry, you may 
> succeed. If you keep interrupts disabled and retry, you never succeed, no 
> matter how long do you wait. I found it experimentally, I don't know 
> reason for that.

Sounds like magic goo..

In any case, try the below, it does the same but is far less horrid.

---
 drivers/cpufreq/speedstep-smi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 0f5326d6f79f..57d31538c248 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
 		return;
 
 	/* Disable IRQs */
+	preempt_disable();
 	local_irq_save(flags);
 
 	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
@@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
 		if (retry) {
 			pr_debug("retry %u, previous result %u, waiting...\n",
 					retry, result);
+			local_irq_restore(flags);
 			mdelay(retry * 50);
+			local_irq_save(flags);
 		}
 		retry++;
 		__asm__ __volatile__(
@@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
 
 	/* enable IRQs */
 	local_irq_restore(flags);
+	preempt_enable();
 
 	if (new_state == state)
 		pr_debug("change to %u MHz succeeded after %u tries "

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 14:14 ` Peter Zijlstra
@ 2014-01-14 19:06   ` Mikulas Patocka
  2014-01-14 20:05     ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Mikulas Patocka @ 2014-01-14 19:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, linux-next, linux-kernel



On Tue, 14 Jan 2014, Peter Zijlstra wrote:

> On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> > drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
> >   preempt_check_resched();
> >   ^
> > 
> > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > preempt_enable_no_resched() from modules") interacting with commit
> > 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> > pm tree.

Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?

> I think that pm commit is a very good example of why the sched/preempt
> patch is a very good idea.
> 
> Also that Changelog fails to explain why enabling interrupts helps. What
> interrupt is required for progress, and how does it make the progress
> happen.

There is no explanation. It's hardware issue and I have no documentation 
for the hardware.


The general problem is that if there are bus-master transfers running (or 
possibly for other hardware reasons), the CPU refuses to change frequency. 
You can wait a little bit and retry and maybe you succeed changing the 
frequency next time.

If you enable interrupts, wait, disable interrupts and retry, you may 
succeed. If you keep interrupts disabled and retry, you never succeed, no 
matter how long do you wait. I found it experimentally, I don't know 
reason for that.

Mikulas

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14  3:26 Stephen Rothwell
@ 2014-01-14 14:14 ` Peter Zijlstra
  2014-01-14 19:06   ` Mikulas Patocka
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2014-01-14 14:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Rafael J. Wysocki,
	linux-next, linux-kernel, Mikulas Patocka

On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
>   preempt_check_resched();
>   ^
> 
> Caused by commit 62b94a08da1b ("sched/preempt: Take away
> preempt_enable_no_resched() from modules") interacting with commit
> 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> pm tree.

I think that pm commit is a very good example of why the sched/preempt
patch is a very good idea.

Also that Changelog fails to explain why enabling interrupts helps. What
interrupt is required for progress, and how does it make the progress
happen.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-01-14  3:26 Stephen Rothwell
  2014-01-14 14:14 ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2014-01-14  3:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Mikulas Patocka

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
  preempt_check_resched();
  ^

Caused by commit 62b94a08da1b ("sched/preempt: Take away
preempt_enable_no_resched() from modules") interacting with commit
24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
pm tree.

For now, I have reverted that pm tree commit.  Please sort this out.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28 10:26   ` Ingo Molnar
@ 2013-10-29  6:00     ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2013-10-29  6:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thierry Reding, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

Hi Ingo,

On Mon, 28 Oct 2013 11:26:04 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thierry Reding <thierry.reding@gmail.com> wrote:
> 
> > On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
> > >                  from /scratch/sfr/next/include/linux/gfp.h:4,
> > >                  from /scratch/sfr/next/include/linux/kmod.h:22,
> > >                  from /scratch/sfr/next/include/linux/module.h:13,
> > >                  from /scratch/sfr/next/block/blk-mq.c:2:
> > > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> > > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
> > >   __ret;        \
> > >   ^
> > > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
> > >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > >         ^
> > > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
> > >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > >       ^
> > > 
> > > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> > > interface more friendly").
> > > 
> > > Since this was also in next-20131025, I applied the following merge fix
> > > commit for today, please fix this in the tip tree.
> > 
> > FWIW I got confirmation on Oct 23 that this had been committed to the
> > tip tree. So I guess it just wasn't pushed yet.
> 
> I merged the fix intoo the linux-next branch earlier today so it 
> should be resolved soon.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28 10:18 ` Thierry Reding
@ 2013-10-28 10:26   ` Ingo Molnar
  2013-10-29  6:00     ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Ingo Molnar @ 2013-10-28 10:26 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel


* Thierry Reding <thierry.reding@gmail.com> wrote:

> On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
> >                  from /scratch/sfr/next/include/linux/gfp.h:4,
> >                  from /scratch/sfr/next/include/linux/kmod.h:22,
> >                  from /scratch/sfr/next/include/linux/module.h:13,
> >                  from /scratch/sfr/next/block/blk-mq.c:2:
> > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
> >   __ret;        \
> >   ^
> > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
> >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> >         ^
> > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
> >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> >       ^
> > 
> > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> > interface more friendly").
> > 
> > Since this was also in next-20131025, I applied the following merge fix
> > commit for today, please fix this in the tip tree.
> 
> FWIW I got confirmation on Oct 23 that this had been committed to the
> tip tree. So I guess it just wasn't pushed yet.

I merged the fix intoo the linux-next branch earlier today so it 
should be resolved soon.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28  9:24 Stephen Rothwell
@ 2013-10-28 10:18 ` Thierry Reding
  2013-10-28 10:26   ` Ingo Molnar
  0 siblings, 1 reply; 245+ messages in thread
From: Thierry Reding @ 2013-10-28 10:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
>                  from /scratch/sfr/next/include/linux/gfp.h:4,
>                  from /scratch/sfr/next/include/linux/kmod.h:22,
>                  from /scratch/sfr/next/include/linux/module.h:13,
>                  from /scratch/sfr/next/block/blk-mq.c:2:
> /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
>   __ret;        \
>   ^
> /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
>   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
>         ^
> /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
>   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
>       ^
> 
> Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> interface more friendly").
> 
> Since this was also in next-20131025, I applied the following merge fix
> commit for today, please fix this in the tip tree.

FWIW I got confirmation on Oct 23 that this had been committed to the
tip tree. So I guess it just wasn't pushed yet.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-10-28  9:24 Stephen Rothwell
  2013-10-28 10:18 ` Thierry Reding
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2013-10-28  9:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
                 from /scratch/sfr/next/include/linux/gfp.h:4,
                 from /scratch/sfr/next/include/linux/kmod.h:22,
                 from /scratch/sfr/next/include/linux/module.h:13,
                 from /scratch/sfr/next/block/blk-mq.c:2:
/scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
/scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
  __ret;        \
  ^
/scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
  ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
        ^
/scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
  ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
      ^

Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
interface more friendly").

Since this was also in next-20131025, I applied the following merge fix
commit for today, please fix this in the tip tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Oct 2013 20:19:27 +1100
Subject: [PATCH] sched/wait: fix missing semicolon

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/wait.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 7f8caa519128..fcc968087f05 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -768,7 +768,7 @@ do {									\
 	int __ret = 0;							\
 	if (!(condition))						\
 		__ret = __wait_event_interruptible_lock_irq(wq,		\
-						condition, lock,)	\
+						condition, lock,);	\
 	__ret;								\
 })
 
-- 
1.8.4.rc3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-04-29  5:45 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2013-04-29  5:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Tom Gundersen, Matt Fleming

[-- Attachment #1: Type: text/plain, Size: 6151 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/firmware/efi/efivars.c: In function 'efivar_release':
drivers/firmware/efi/efivars.c:300:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efivars.c: In function 'efivar_create':
drivers/firmware/efi/efivars.c:341:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efivars.c:341:12: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivar_create_sysfs_entry':
drivers/firmware/efi/efivars.c:420:13: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'create_efivars_bin_attributes':
drivers/firmware/efi/efivars.c:460:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c:470:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivar_update_sysfs_entries':
drivers/firmware/efi/efivars.c:527:8: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivars_sysfs_callback':
drivers/firmware/efi/efivars.c:551:8: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/inode.c: In function 'efivarfs_create':
fs/efivarfs/inode.c:115:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/inode.c:115:6: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/inode.c:139:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c: In function 'efivarfs_file_write':
fs/efivarfs/file.c:35:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c:35:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/file.c:62:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c: In function 'efivarfs_file_read':
fs/efivarfs/file.c:81:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c: In function 'efivarfs_callback':
fs/efivarfs/super.c:132:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/super.c:132:8: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c:142:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c:166:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efi-pstore.c: In function 'efi_pstore_read_func':
drivers/firmware/efi/efi-pstore.c:77:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efi-pstore.c:77:16: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efi-pstore.c: In function 'efivars_pstore_init':
drivers/firmware/efi/efi-pstore.c:225:22: warning: assignment makes pointer from integer without a cast [enabled by default]

Probably caused by commits d68772b7c83f ("efivarfs: Move to fs/efivarfs")
and/or a9499fa7cd3f ("efi: split efisubsystem from efivars") interacting
with some header inclusion changes in the rest of today's trees.

See Rule 1 from Documentation/SubmitChecklist.

I have applied the following merge fix patch for today (this won't quite
apply to the tip tree due to the other patch adding linux/magic.h to
fs/efivarfs/super.c, but that could be applied as well):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Apr 2013 15:34:28 +1000
Subject: [PATCH] efivars: use of kmalloc etc requires the inclusion of slab.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/firmware/efi/efivars.c | 1 +
 fs/efivarfs/file.c             | 1 +
 fs/efivarfs/inode.c            | 1 +
 fs/efivarfs/super.c            | 1 +
 drivers/firmware/efi/efi-pstore.c | 1 +
 5 files changed, 5 insertions(+)

diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c
index f8f5e5d..66928a3 100644
--- a/drivers/firmware/efi/efivars.c
+++ b/drivers/firmware/efi/efivars.c
@@ -68,6 +68,7 @@
 #include <linux/efi.h>
 #include <linux/module.h>
 #include <linux/ucs2_string.h>
+#include <linux/slab.h>
 
 #define EFIVARS_VERSION "0.08"
 #define EFIVARS_DATE "2004-May-17"
diff --git a/fs/efivarfs/file.c b/fs/efivarfs/file.c
index ede07fc..bfb5315 100644
--- a/fs/efivarfs/file.c
+++ b/fs/efivarfs/file.c
@@ -9,6 +9,7 @@
 
 #include <linux/efi.h>
 #include <linux/fs.h>
+#include <linux/slab.h>
 
 #include "internal.h"
 
diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c
index 640e289..7e787fb 100644
--- a/fs/efivarfs/inode.c
+++ b/fs/efivarfs/inode.c
@@ -10,6 +10,7 @@
 #include <linux/efi.h>
 #include <linux/fs.h>
 #include <linux/ctype.h>
+#include <linux/slab.h>
 
 #include "internal.h"
 
diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 1fa5e6d..94d9192 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -12,6 +12,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/pagemap.h>
+#include <linux/slab.h>
 #include <linux/magic.h>
 
 #include "internal.h"
diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c
index 221ad1b..0242795 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -2,6 +2,7 @@
 #include <linux/module.h>
 #include <linux/pstore.h>
 #include <linux/ucs2_string.h>
+#include <linux/slab.h>
 
 #define DUMP_NAME_LEN 52
 

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-02-14  2:30 Stephen Rothwell
@ 2013-02-21  2:04 ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2013-02-21  2:04 UTC (permalink / raw)
  To: Zhang Rui
  Cc: linux-next, linux-kernel, Jacob Pan, Arjan van de Ven,
	Clark Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Hi all,

On Thu, 14 Feb 2013 13:30:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/thermal/intel_powerclamp.c: In function 'clamp_thread':
> drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function)
> 
> Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new
> header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel
> PowerClamp Driver") from the thermal tree.
> 
> I applied this merge fix patch and can carry it as necessary:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 14 Feb 2013 13:26:22 +1100
> Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/thermal/intel_powerclamp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
> index ab3ed90..b40b37c 100644
> --- a/drivers/thermal/intel_powerclamp.c
> +++ b/drivers/thermal/intel_powerclamp.c
> @@ -50,6 +50,7 @@
>  #include <linux/tick.h>
>  #include <linux/debugfs.h>
>  #include <linux/seq_file.h>
> +#include <linux/sched/rt.h>
>  
>  #include <asm/nmi.h>
>  #include <asm/msr.h>

The above fix is now needed when the thermal tree is merged with Linus'
tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-02-14  2:30 Stephen Rothwell
  2013-02-21  2:04 ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2013-02-14  2:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jacob Pan, Arjan van de Ven, Zhang Rui,
	Clark Williams

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/thermal/intel_powerclamp.c: In function 'clamp_thread':
drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function)

Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new
header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel
PowerClamp Driver") from the thermal tree.

I applied this merge fix patch and can carry it as necessary:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 14 Feb 2013 13:26:22 +1100
Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/thermal/intel_powerclamp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
index ab3ed90..b40b37c 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -50,6 +50,7 @@
 #include <linux/tick.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/sched/rt.h>
 
 #include <asm/nmi.h>
 #include <asm/msr.h>
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-02-02  5:04 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2013-02-02  5:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Sukadev Bhattiprolu, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 'power7_events_attr[0]') [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 'power7_events_attr[1]') [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 'power7_events_attr[2]') [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 'power7_events_attr[3]') [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 'power7_events_attr[4]') [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 'power7_events_attr[5]') [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 'power7_events_attr[6]') [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 'power7_events_attr[7]') [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 'power7_events_attr[8]') [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 'power7_events_attr[9]') [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 'power7_events_attr[10]') [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 'power7_events_attr[11]') [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 'power7_events_attr[12]') [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 'power7_events_attr[13]') [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 'power7_events_attr[14]') [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 'power7_events_attr[15]') [-Werror]

Caused by commit 1c53a270724d ("perf/POWER7: Make generic event
translations available in sysfs").

I have used the tip tree from 20130128 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-20  4:54       ` Stephen Rothwell
@ 2012-08-20 15:09         ` Paul E. McKenney
  0 siblings, 0 replies; 245+ messages in thread
From: Paul E. McKenney @ 2012-08-20 15:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Mon, Aug 20, 2012 at 02:54:04PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Does the following help?
> 
> Yes, that fixes the warnings.  Please submit those two patches to the tip
> folks ASAP as I can't build the tip tree without them.

Will do.  Unless you tell me otherwise, with your Tested-by.

							Thanx, Paul

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-17 11:50     ` Paul E. McKenney
@ 2012-08-20  4:54       ` Stephen Rothwell
  2012-08-20 15:09         ` Paul E. McKenney
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2012-08-20  4:54 UTC (permalink / raw)
  To: paulmck
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Hi Paul,

On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Does the following help?

Yes, that fixes the warnings.  Please submit those two patches to the tip
folks ASAP as I can't build the tip tree without them.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-17  0:56   ` Stephen Rothwell
@ 2012-08-17 11:50     ` Paul E. McKenney
  2012-08-20  4:54       ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Paul E. McKenney @ 2012-08-17 11:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Fri, Aug 17, 2012 at 10:56:33AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> > > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> > > 
> > > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> > > infrastructure").
> > > 
> > > I have used the tip tree from next-20120814 for today.
> > 
> > My first reaction was "we tested that!!!", but I see the conversion
> > from while(1) to do-while.  Does the following cure it?
> 
> Yes, that fixes the build problem.
> 
> However, the same commit is also responsible for all these new warnings:
> 
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task':
> drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park':
> drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task':
> drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void
> drivers/infiniband/hw/ehca/ehca_irq.c: At top level:
> drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type
> 
> Please address these.

Does the following help?

							Thanx, Paul

------------------------------------------------------------------------

infiniband: ehca: Fix compiler warnings

Fix comp_task() to return void to match smp_hotplug_thread's thread_fn
member, and adjust indirection on the ->cpu_comp_threads per-CPU
member of the ehca_comp_pool structure.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index 83a0095..8615d7c 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -707,7 +707,7 @@ static void queue_comp_task(struct ehca_cq *__cq)
 	BUG_ON(!cpu_online(cpu_id));
 
 	cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
-	thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
+	thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
 	BUG_ON(!cct || !thread);
 
 	spin_lock_irqsave(&cct->task_lock, flags);
@@ -716,7 +716,7 @@ static void queue_comp_task(struct ehca_cq *__cq)
 	if (cq_jobs > 0) {
 		cpu_id = find_next_online_cpu(pool);
 		cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
-		thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
+		thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
 		BUG_ON(!cct || !thread);
 	}
 	__queue_comp_task(__cq, cct, thread);
@@ -761,7 +761,7 @@ static void comp_task_park(unsigned int cpu)
 
 	cpu = find_next_online_cpu(pool);
 	target = per_cpu_ptr(pool->cpu_comp_tasks, cpu);
-	thread = per_cpu_ptr(pool->cpu_comp_threads, cpu);
+	thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu);
 	spin_lock_irq(&target->task_lock);
 	list_for_each_entry_safe(cq, tmp, &list, entry) {
 		list_del(&cq->entry);
@@ -788,7 +788,7 @@ static int comp_task_should_run(unsigned int cpu)
 	return cct->cq_jobs;
 }
 
-static int comp_task(unsigned int cpu)
+static void comp_task(unsigned int cpu)
 {
 	struct ehca_cpu_comp_task *cct = this_cpu_ptr(pool->cpu_comp_tasks);
 	int cql_empty;

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-16 19:46 ` Paul E. McKenney
@ 2012-08-17  0:56   ` Stephen Rothwell
  2012-08-17 11:50     ` Paul E. McKenney
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2012-08-17  0:56 UTC (permalink / raw)
  To: paulmck
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi Paul,

On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> > 
> > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> > infrastructure").
> > 
> > I have used the tip tree from next-20120814 for today.
> 
> My first reaction was "we tested that!!!", but I see the conversion
> from while(1) to do-while.  Does the following cure it?

Yes, that fixes the build problem.

However, the same commit is also responsible for all these new warnings:

drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task':
drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park':
drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task':
drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void
drivers/infiniband/hw/ehca/ehca_irq.c: At top level:
drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type

Please address these.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-16  3:12 Stephen Rothwell
@ 2012-08-16 19:46 ` Paul E. McKenney
  2012-08-17  0:56   ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Paul E. McKenney @ 2012-08-16 19:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> 
> Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> infrastructure").
> 
> I have used the tip tree from next-20120814 for today.

My first reaction was "we tested that!!!", but I see the conversion
from while(1) to do-while.  Does the following cure it?

							Thanx, Paul

------------------------------------------------------------------------

infiniband: ehca: Fix while->do-while conversion typo

This commit just adds a needed semicolon.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index 4eeac40..83a0095 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -668,7 +668,7 @@ static int find_next_online_cpu(struct ehca_comp_pool *pool)
 		if (cpu >= nr_cpu_ids)
 			cpu = cpumask_first(cpu_online_mask);
 		pool->last_cpu = cpu;
-	} while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active)
+	} while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active);
 	spin_unlock_irqrestore(&pool->last_cpu_lock, flags);
 
 	return cpu;

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-08-16  3:12 Stephen Rothwell
  2012-08-16 19:46 ` Paul E. McKenney
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2012-08-16  3:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Paul E. McKenney, Rusty Russell,
	Namhyung Kim, Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'

Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
infrastructure").

I have used the tip tree from next-20120814 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-21 12:19     ` Alan Cox
@ 2012-03-21 12:29       ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2012-03-21 12:29 UTC (permalink / raw)
  To: Alan Cox
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hi Alan,

On Wed, 21 Mar 2012 12:19:54 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> We don't even have a sep_driver.c any more. The massive rework of the SEP
> driver dealt with this.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
  2012-03-21  9:53     ` Alan Cox
@ 2012-03-21 12:19     ` Alan Cox
  2012-03-21 12:29       ` Stephen Rothwell
  2 siblings, 1 reply; 245+ messages in thread
From: Alan Cox @ 2012-03-21 12:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

We don't even have a sep_driver.c any more. The massive rework of the SEP
driver dealt with this.

Alan

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
@ 2012-03-21  9:53     ` Alan Cox
  2012-03-21 12:19     ` Alan Cox
  2 siblings, 0 replies; 245+ messages in thread
From: Alan Cox @ 2012-03-21  9:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

I thought it was but apparently it got lost or I dropped the ball. I'll
sort it once git.kernel.org is back and I can pull a currentish -next
tree.

Alan

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
@ 2012-03-20 22:32     ` Greg KH
  2012-03-21  9:53     ` Alan Cox
  2012-03-21 12:19     ` Alan Cox
  2 siblings, 0 replies; 245+ messages in thread
From: Greg KH @ 2012-03-20 22:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

On Wed, Mar 21, 2012 at 09:00:38AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

I never got a patch from Alan or anyone else to do this :(

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-08 18:00 ` Greg KH
@ 2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
                       ` (2 more replies)
  0 siblings, 3 replies; 245+ messages in thread
From: Stephen Rothwell @ 2012-03-20 22:00 UTC (permalink / raw)
  To: Greg KH
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Hi all,

On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > 
> > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > 
> > Following previous instructions, I have disabled the staging tree driver
> > using this patch (pending a fix in the tip tree):
> 
> Looks good to me.  Alan, care to send me an update that fixes this
> driver for real?

Was this ever fixed?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-08  4:21 Stephen Rothwell
@ 2012-03-08 18:00 ` Greg KH
  2012-03-20 22:00   ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Greg KH @ 2012-03-08 18:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> 
> Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> 
> Following previous instructions, I have disabled the staging tree driver
> using this patch (pending a fix in the tip tree):

Looks good to me.  Alan, care to send me an update that fixes this
driver for real?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-03-08  4:21 Stephen Rothwell
  2012-03-08 18:00 ` Greg KH
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2012-03-08  4:21 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Greg KH, Alan Cox, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory

Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").

Following previous instructions, I have disabled the staging tree driver
using this patch (pending a fix in the tip tree):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Mar 2012 15:15:44 +1100
Subject: [PATCH] staging: disable the sep driver due to breakage

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/sep/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/sep/Kconfig b/drivers/staging/sep/Kconfig
index 92bf166..cd95ca2 100644
--- a/drivers/staging/sep/Kconfig
+++ b/drivers/staging/sep/Kconfig
@@ -1,6 +1,6 @@
 config DX_SEP
 	tristate "Discretix SEP driver"
-	depends on PCI
+	depends on PCI && BROKEN
 	help
 	  Discretix SEP driver; used for the security processor subsystem
 	  on bard the Intel Mobile Internet Device.
-- 
1.7.9.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-02-24  3:47 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2012-02-24  3:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David Howells

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/android/binder.c: In function 'task_get_unused_fd_flags':
drivers/staging/android/binder.c:383:39: error: request for member 'fds_bits' in something not a structure or union

Caused by commit 1fd36adcd98c ("Replace the fd_sets in struct fdtable
with an array of unsigned longs").

I have used the tip tree from next-20120223 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-02-24  3:34 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2012-02-24  3:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64_allmodconfig)
failed like this:

/opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy:arch/x86/vdso/vdso-note-x32.o: Invalid bfd target

I appears that we need a 2.22 binutils :-(

$ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --version
GNU objcopy (GNU Binutils) 2.21
$ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --help
	.
	.
/opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 24 Feb 2012 14:27:17 +1100
Subject: [PATCH] x86: mark X86_X32_ABI broken for now until I get a better
 binutils

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 59c5b9c..e63a4dd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2159,7 +2159,7 @@ config IA32_AOUT
 
 config X86_X32_ABI
 	bool "x32 ABI for 64-bit mode (EXPERIMENTAL)"
-	depends on X86_64 && IA32_EMULATION && EXPERIMENTAL
+	depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN
 	---help---
 	  Include code to run binaries for the x32 native 32-bit ABI
 	  for 64-bit processors.  An x32 process gets access to the
-- 
1.7.9.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-10-05  8:46 ` Peter Zijlstra
@ 2011-10-11  6:15   ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2011-10-11  6:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Huang Ying, David Miller, netdev

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

Hi all,

On Wed, 05 Oct 2011 10:46:13 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> > net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> > net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> > net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> > net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > 
> > Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> > interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> > net/rds/xlist.h with llist") from the net tree.  The former commit
> > removes the declarations of llist_del_first() and llist_add_batch() with
> > no explanation (and probably by accident since the definitions still
> > exist).
> 
> Ugh yes, my bad. Ingo objected to inlining all those functions and I
> then screwed up. There are no users of those two functions in my tree.

So can we have that fixed, please?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-10-05  6:25 Stephen Rothwell
@ 2011-10-05  8:46 ` Peter Zijlstra
  2011-10-11  6:15   ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Peter Zijlstra @ 2011-10-05  8:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Huang Ying, David Miller, netdev

On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> 
> Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> net/rds/xlist.h with llist") from the net tree.  The former commit
> removes the declarations of llist_del_first() and llist_add_batch() with
> no explanation (and probably by accident since the definitions still
> exist).

Ugh yes, my bad. Ingo objected to inlining all those functions and I
then screwed up. There are no users of those two functions in my tree.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-10-05  6:25 Stephen Rothwell
  2011-10-05  8:46 ` Peter Zijlstra
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2011-10-05  6:25 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Huang Ying, David Miller, netdev

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
net/rds/xlist.h with llist") from the net tree.  The former commit
removes the declarations of llist_del_first() and llist_add_batch() with
no explanation (and probably by accident since the definitions still
exist).

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 5 Oct 2011 17:16:29 +1100
Subject: [PATCH] llist: add back llist_add_batch and llist_del_first

Commit 1230db8e1543 ("llist: Make some llist functions inline") appears
to have deleted the definitions by accident.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/llist.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index 837fb4a..7287734 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -178,4 +178,10 @@ static inline struct llist_node *llist_del_all(struct llist_head *head)
 {
 	return xchg(&head->first, NULL);
 }
+
+extern bool llist_add_batch(struct llist_node *new_first,
+			    struct llist_node *new_last,
+			    struct llist_head *head);
+extern struct llist_node *llist_del_first(struct llist_head *head);
+
 #endif /* LLIST_H */
-- 
1.7.6.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-06-27  4:22 Stephen Rothwell
@ 2011-06-28 10:55 ` Stijn Devriendt
  0 siblings, 0 replies; 245+ messages in thread
From: Stijn Devriendt @ 2011-06-28 10:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

I've already reported this to Thomas with a patch attached.

See https://lkml.org/lkml/2011/6/25/62

Regards,
Stijn

On Mon, Jun 27, 2011 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/i8253.c: In function 'setup_pit_timer':
> arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init'
> arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function)
>
> Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent").
> clockevent_i8253_init() doesn't appear to be declared in any header file
> even though it is introduced as a global function in commit 9f9119424bbc
> ("i8253: Create common clockevent implementation").  Similarly for
> i8253_clockevent.
>
> I have used the tip tree from next-20110624 for today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-06-27  4:22 Stephen Rothwell
  2011-06-28 10:55 ` Stijn Devriendt
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2011-06-27  4:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kernel/i8253.c: In function 'setup_pit_timer':
arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init'
arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function)

Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent").
clockevent_i8253_init() doesn't appear to be declared in any header file
even though it is introduced as a global function in commit 9f9119424bbc
("i8253: Create common clockevent implementation").  Similarly for
i8253_clockevent.

I have used the tip tree from next-20110624 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-04-01  2:00 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2011-04-01  2:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dirk Brandewie, Ben Dooks, Jean Delvare

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/i2c/busses/i2c-designware-core.c: In function 'i2c_dw_wait_bus_not_busy':
drivers/i2c/busses/i2c-designware-core.c:321: error: implicit declaration of function 'mdelay'

Caused by commit 800c56383dcb ("i2c-designware: split of i2c-designware.c
into core and bus specific parts") from the bjdooks-i2c tree and exposed
by commit ca444564a947 ("x86: Stop including <linux/delay.h> in two asm
header files").

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 Apr 2011 12:48:53 +1100
Subject: [PATCH] i2c-designware: mdelay use needs linux/delay.h inclusion

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/i2c/busses/i2c-designware-core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 299e717..f87e25a 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -25,6 +25,7 @@
  * ----------------------------------------------------------------------------
  *
  */
+#include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/errno.h>
 #include <linux/err.h>
-- 
1.7.4.1


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 22:47       ` Stephen Rothwell
@ 2011-02-18  3:54         ` Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2011-02-18  3:54 UTC (permalink / raw)
  To: Michal Marek
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hi Michal,

On Fri, 18 Feb 2011 09:47:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
> >
> > > _Maybe_ we could work around it by letting fixdep remove the actual
> > > source file from the list of dependencies in the .cmd file. The
> > > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > > .cmd file is only needed for additional dependencies on headers. Let's
> > > see what else breaks then ;).
> > 
> > It seems to work for me. Can you try the patch below? It needs to be
> > applied before merging 9599ec0 to have any effect.
> 
> Thanks, I will apply this as a fix on top of Linus' tree before I merge
> anything else.  It looks simple enough that Linus may take it as a fix
> right now.   Better to convince ourselves first, though, right?

That patch fixed the problem for me and has caused no obvious problems.

Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 15:02     ` Michal Marek
  2011-02-17 17:11       ` Ingo Molnar
@ 2011-02-17 22:47       ` Stephen Rothwell
  2011-02-18  3:54         ` Stephen Rothwell
  1 sibling, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2011-02-17 22:47 UTC (permalink / raw)
  To: Michal Marek
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Hi Michal,

On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> > _Maybe_ we could work around it by letting fixdep remove the actual
> > source file from the list of dependencies in the .cmd file. The
> > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > .cmd file is only needed for additional dependencies on headers. Let's
> > see what else breaks then ;).
> 
> It seems to work for me. Can you try the patch below? It needs to be
> applied before merging 9599ec0 to have any effect.

Thanks, I will apply this as a fix on top of Linus' tree before I merge
anything else.  It looks simple enough that Linus may take it as a fix
right now.   Better to convince ourselves first, though, right?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 15:02     ` Michal Marek
@ 2011-02-17 17:11       ` Ingo Molnar
  2011-02-17 22:47       ` Stephen Rothwell
  1 sibling, 0 replies; 245+ messages in thread
From: Ingo Molnar @ 2011-02-17 17:11 UTC (permalink / raw)
  To: Michal Marek
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Fenghua Yu


* Michal Marek <mmarek@suse.cz> wrote:

> @@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
>  		if (strrcmp(s, "include/generated/autoconf.h") &&
>  		    strrcmp(s, "arch/um/include/uml-config.h") &&
>  		    strrcmp(s, ".ver")) {
> -			printf("  %s \\\n", s);
> +			/* Do not output the first dependency (the
> +			 * source file), so that kbuild is not confused
> +			 * if a .c file is rewritten into .S or vice
> +			 * versa.
> +			 */

Just a really minor nitpick, please use the standard comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 13:18   ` Michal Marek
@ 2011-02-17 15:02     ` Michal Marek
  2011-02-17 17:11       ` Ingo Molnar
  2011-02-17 22:47       ` Stephen Rothwell
  0 siblings, 2 replies; 245+ messages in thread
From: Michal Marek @ 2011-02-17 15:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

On Thu, Feb 17, 2011 at 02:18:18PM +0100, Michal Marek wrote:
> On 17.2.2011 04:47, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> failed like this:
> >>
> >> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> >>
> >> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> >> Convert memmove() to assembly file and fix return value bug") interacting
> >> with our build system.
> >>
> >> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> >> before merging the tip tree) from my object tree, it built correctly.
> > 
> > I am still getting this (of course).
> > 
> > Michal, is there anything that the kbuild system can do for us here?
> > Basically we have changed from using a .c file to generate a .o to using
> > a .S but the build system does not regenerate the .cmd file.
> 
> _Maybe_ we could work around it by letting fixdep remove the actual
> source file from the list of dependencies in the .cmd file. The
> dependency on the .c / .S / whatever file is given by the Makefiles, the
> .cmd file is only needed for additional dependencies on headers. Let's
> see what else breaks then ;).

It seems to work for me. Can you try the patch below? It needs to be
applied before merging 9599ec0 to have any effect.

Michal

From: Michal Marek <mmarek@suse.cz>
Subject: [PATCH] fixdep: Do not record dependency on the source file itself

The dependency is already expressed by the Makefiles, storing it in the
.cmd file breaks build if a .c file is replaced by .S or vice versa,
because the .cmd file contains

foo/bar.o: foo/bar.c ...

foo/bar.c ... :

so the foo/bar.c -> foo/bar.o rule triggers even if there is no
foo/bar.c anymore.

Signed-off-by: Michal Marek <mmarek@suse.cz>

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index c9a16ab..9264725 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -315,6 +315,7 @@ static void parse_dep_file(void *map, size_t len)
 	char *end = m + len;
 	char *p;
 	char s[PATH_MAX];
+	int first;
 
 	p = strchr(m, ':');
 	if (!p) {
@@ -327,6 +328,7 @@ static void parse_dep_file(void *map, size_t len)
 
 	clear_config();
 
+	first = 1;
 	while (m < end) {
 		while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
 			m++;
@@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
 		if (strrcmp(s, "include/generated/autoconf.h") &&
 		    strrcmp(s, "arch/um/include/uml-config.h") &&
 		    strrcmp(s, ".ver")) {
-			printf("  %s \\\n", s);
+			/* Do not output the first dependency (the
+			 * source file), so that kbuild is not confused
+			 * if a .c file is rewritten into .S or vice
+			 * versa.
+			 */
+			if (!first)
+				printf("  %s \\\n", s);
 			do_config_file(s);
 		}
+		first = 0;
 		m = p + 1;
 	}
 	printf("\n%s: $(deps_%s)\n\n", target, target);

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17  3:47 ` Stephen Rothwell
@ 2011-02-17 13:18   ` Michal Marek
  2011-02-17 15:02     ` Michal Marek
  0 siblings, 1 reply; 245+ messages in thread
From: Michal Marek @ 2011-02-17 13:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

On 17.2.2011 04:47, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
>>
>> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
>> Convert memmove() to assembly file and fix return value bug") interacting
>> with our build system.
>>
>> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
>> before merging the tip tree) from my object tree, it built correctly.
> 
> I am still getting this (of course).
> 
> Michal, is there anything that the kbuild system can do for us here?
> Basically we have changed from using a .c file to generate a .o to using
> a .S but the build system does not regenerate the .cmd file.

_Maybe_ we could work around it by letting fixdep remove the actual
source file from the list of dependencies in the .cmd file. The
dependency on the .c / .S / whatever file is given by the Makefiles, the
.cmd file is only needed for additional dependencies on headers. Let's
see what else breaks then ;).

Michal

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-01-31  4:42 Stephen Rothwell
@ 2011-02-17  3:47 ` Stephen Rothwell
  2011-02-17 13:18   ` Michal Marek
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2011-02-17  3:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu, Michal Marek

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

Hi all,

On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> 
> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> Convert memmove() to assembly file and fix return value bug") interacting
> with our build system.
> 
> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> before merging the tip tree) from my object tree, it built correctly.

I am still getting this (of course).

Michal, is there anything that the kbuild system can do for us here?
Basically we have changed from using a .c file to generate a .o to using
a .S but the build system does not regenerate the .cmd file.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-01-31  4:42 Stephen Rothwell
  2011-02-17  3:47 ` Stephen Rothwell
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2011-01-31  4:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu, Michal Marek

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory

Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
Convert memmove() to assembly file and fix return value bug") interacting
with our build system.

After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
before merging the tip tree) from my object tree, it built correctly.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-10-19  5:13 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2010-10-19  5:13 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/bin/sh: /scratch/sfr/x86_64_allmodconfig/scripts/recordmcount: No such file or directory

I use O=/scratch/sfr/x86_64_allmodconfig in this build.  The same
happened yesterday, but it fixed itself when I rebuilt for other
reasons.  Andrew has also reported this so I applied the patch you
suggested.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2010-05-10  4:49 Stephen Rothwell
@ 2010-05-10  5:09 ` H. Peter Anvin
  0 siblings, 0 replies; 245+ messages in thread
From: H. Peter Anvin @ 2010-05-10  5:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel

On 05/09/2010 09:49 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory
> drivers/misc/vmware_balloon.c: In function 'vmballoon_init':
> drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform'
> 
> Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up
> the hypervisor layer").  (Yes, I know this has already been reported.)
> 
> I have used the version of the tip tree from next-20100507 for today.

Working on it.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-05-10  4:49 Stephen Rothwell
  2010-05-10  5:09 ` H. Peter Anvin
  0 siblings, 1 reply; 245+ messages in thread
From: Stephen Rothwell @ 2010-05-10  4:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory
drivers/misc/vmware_balloon.c: In function 'vmballoon_init':
drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform'

Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up
the hypervisor layer").  (Yes, I know this has already been reported.)

I have used the version of the tip tree from next-20100507 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-03-12  4:00 Stephen Rothwell
  0 siblings, 0 replies; 245+ messages in thread
From: Stephen Rothwell @ 2010-03-12  4:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Frederic Weisbecker

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".perf_arch_fetch_caller_regs" [fs/xfs/xfs.ko] undefined!
ERROR: ".perf_arch_fetch_caller_regs" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!

Caused by commit 5331d7b84613b8325362dde53dc2bff2fb87d351 ("perf:
Introduce new perf_fetch_caller_regs() for hot regs snapshot") from the
tip tree.  Presumably commit 639fe4b12f92b54c9c3b38c82cdafaa38cfd3e63
("perf: export perf_trace_regs and perf_arch_fetch_caller_regs") should
have exported the weak version as well as the x86 one.

I have used the version of the tip tree from next-20100311 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 245+ messages in thread

end of thread, back to index

Thread overview: 245+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-29  3:04 linux-next: build failure after merge of the tip tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2019-11-21  3:54 Stephen Rothwell
2019-11-21  8:36 ` Peter Zijlstra
2019-11-21 18:37 ` Alex Deucher
2019-11-18  3:11 Stephen Rothwell
2019-11-18  9:49 ` Jiri Slaby
2019-11-18 12:49 ` Borislav Petkov
2019-10-21  2:13 Stephen Rothwell
2019-10-21  5:51 ` Ingo Molnar
2019-10-21  6:37   ` Stephen Rothwell
2019-10-10  2:14 Stephen Rothwell
2019-10-10  8:02 ` Ingo Molnar
2019-10-10 11:23   ` Stephen Rothwell
2019-10-10 13:44     ` Daniel Vetter
2019-11-06  2:53 ` Stephen Rothwell
2019-11-27 23:39   ` Stephen Rothwell
2019-08-29  6:20 Stephen Rothwell
2019-08-29  7:46 ` Peter Zijlstra
2019-08-29 12:24   ` Thomas Gleixner
2019-08-29 13:04     ` Peter Zijlstra
2019-08-08  4:48 Stephen Rothwell
2019-08-01  3:38 Stephen Rothwell
2019-07-09  6:54 Stephen Rothwell
2019-07-10  0:01 ` Stephen Rothwell
2019-07-10 18:21   ` Ilya Dryomov
2019-07-10 21:38     ` Stephen Rothwell
2019-07-02  5:33 Stephen Rothwell
2019-07-02 10:28 ` David Sterba
2019-07-02 12:57   ` Stephen Rothwell
2019-07-08  6:50   ` Stephen Rothwell
2019-06-25  6:04 Stephen Rothwell
2019-06-25  6:23 ` Kalle Valo
2019-06-25  6:26   ` Thomas Gleixner
2019-06-25  6:36   ` Stephen Rothwell
2019-06-25  6:51     ` Kalle Valo
2019-06-25  6:56     ` Thomas Gleixner
2019-06-25  7:47       ` Kalle Valo
2019-07-09  0:09 ` Stephen Rothwell
2019-07-09  3:46 ` Stephen Rothwell
2018-11-06  0:43 Stephen Rothwell
2018-08-08 23:24 Stephen Rothwell
2018-08-09  9:41 ` Joerg Roedel
2018-04-03  5:41 Stephen Rothwell
2018-04-03  9:30 ` Peter Zijlstra
2018-04-03 12:39 ` David Howells
2018-04-03 12:42   ` Peter Zijlstra
2018-04-03 12:41 ` David Howells
2017-11-08  2:47 Stephen Rothwell
2017-11-08  3:01 ` Josh Poimboeuf
2017-11-08  7:35   ` Stephen Rothwell
2017-11-08  9:18   ` Ingo Molnar
2017-11-08 12:14     ` Stephen Rothwell
2017-11-09  6:18       ` Ingo Molnar
2017-11-08 13:17     ` Josh Poimboeuf
2017-11-09  3:03     ` Stephen Rothwell
2017-11-01 10:51 Stephen Rothwell
2017-11-01 14:32 ` Kees Cook
2017-06-28  3:43 Stephen Rothwell
2017-06-28  4:00 ` jeffy
2017-06-28  4:24   ` Stephen Rothwell
2017-07-03  3:01 ` Stephen Rothwell
2017-05-02  3:17 Stephen Rothwell
2017-04-24  3:32 Stephen Rothwell
2017-04-24  5:31 ` Ingo Molnar
2017-04-05  3:36 Stephen Rothwell
2017-04-05  7:24 ` Mikko Perttunen
2016-12-07  1:37 Stephen Rothwell
2016-12-07  7:45 ` Ingo Molnar
2016-12-07  8:12   ` Jiri Olsa
2016-12-07 14:49     ` Arnaldo Carvalho de Melo
2016-12-07 18:56       ` Ingo Molnar
2016-12-07 20:32         ` Stephen Rothwell
2016-11-17  3:22 Stephen Rothwell
2016-09-29  3:20 Stephen Rothwell
2016-09-29 12:25 ` Rafael J. Wysocki
2016-09-29 15:54   ` Chen, Yu C
2016-09-29 20:50     ` Rafael J. Wysocki
2016-09-21  3:23 Stephen Rothwell
2016-09-21  6:44 ` Viresh Kumar
2016-07-18  8:29 Stephen Rothwell
2016-07-18 14:27 ` Paul Gortmaker
2016-07-18  5:15 Stephen Rothwell
2016-04-18  3:03 Stephen Rothwell
2016-04-14  2:14 Stephen Rothwell
2016-04-14 12:35 ` Arnaldo Carvalho de Melo
2016-04-14 12:55   ` Michael Ellerman
2016-04-14 15:08     ` Arnaldo Carvalho de Melo
2016-04-15 21:15 ` Arnaldo Carvalho de Melo
2016-04-15 21:28   ` Arnaldo Carvalho de Melo
2016-04-17 12:12     ` Jiri Olsa
2016-04-17 13:04       ` Jiri Olsa
2016-04-18 13:24         ` Arnaldo Carvalho de Melo
2016-04-18 13:28           ` Jiri Olsa
2016-03-01  1:29 Stephen Rothwell
2016-03-01  7:07 ` Ingo Molnar
2016-03-01  7:28   ` Sedat Dilek
2016-03-01  7:39     ` H. Peter Anvin
2016-03-01  8:41       ` Sedat Dilek
2016-03-01  9:45       ` Ingo Molnar
2016-03-01  9:40   ` Stephen Rothwell
2015-09-16  1:30 Stephen Rothwell
2015-09-16  4:53 ` David Miller
2015-09-16  0:12 Stephen Rothwell
2015-09-16  6:16 ` Jiri Olsa
2015-09-16  6:38   ` Jiri Olsa
2015-09-16  7:30     ` Stephen Rothwell
2015-09-16 14:17       ` Arnaldo Carvalho de Melo
2015-09-17  0:34   ` Stephen Rothwell
2015-09-30  2:56     ` Stephen Rothwell
2015-09-30  6:08       ` Jiri Olsa
2015-09-30  6:17         ` Stephen Rothwell
2015-07-28  5:33 Stephen Rothwell
2015-07-28 16:34 ` Luis R. Rodriguez
2015-07-28 18:17   ` Luis R. Rodriguez
2015-07-28  2:43 Stephen Rothwell
2015-07-28  8:41 ` Sudeep Holla
2015-07-28  9:43   ` Gregory CLEMENT
2015-07-15  1:01 Stephen Rothwell
2015-07-08  0:56 Stephen Rothwell
2015-07-08  9:40 ` Thomas Gleixner
2015-06-12 10:51 Michael Ellerman
     [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
2015-06-12 21:22   ` David Miller
2015-06-12 21:25     ` Chickles, Derek
2015-06-09  7:15 Stephen Rothwell
2015-04-07  7:18 Stephen Rothwell
2015-04-07  8:48 ` Ingo Molnar
2015-04-07  8:56   ` Daniel Borkmann
2015-04-07  9:05     ` Stephen Rothwell
2015-04-07 11:13       ` Daniel Borkmann
2015-04-07 16:18         ` Alexei Starovoitov
2015-04-07 19:54           ` Daniel Borkmann
2015-04-08  5:03             ` Stephen Rothwell
2015-04-15  1:25               ` Stephen Rothwell
2015-04-07  8:53 ` Peter Zijlstra
2015-03-30  6:13 Stephen Rothwell
2015-03-30  7:15 ` Russell King - ARM Linux
2015-03-30  8:08   ` Stephen Rothwell
2015-03-30 14:57     ` Nathan Lynch
2015-03-30 15:08       ` Russell King - ARM Linux
2015-03-30 15:24         ` Nathan Lynch
2015-04-13 23:34         ` Stephen Rothwell
2014-07-25  4:45 Stephen Rothwell
2014-07-29 23:56 ` Stephen Rothwell
2014-07-30  3:10   ` John Stultz
2014-06-04  6:05 Stephen Rothwell
2014-06-04 10:49 ` Thomas Gleixner
2014-06-04 14:46   ` Linus Torvalds
2014-06-04 16:23   ` Olof Johansson
2014-06-04 20:02     ` Thomas Gleixner
2014-05-23  7:14 Stephen Rothwell
2014-05-29  1:38 ` Stephen Rothwell
2014-04-24  3:51 Stephen Rothwell
2014-02-12  2:41 Stephen Rothwell
2014-02-12  4:48 ` Preeti U Murthy
2014-02-11  3:00 Stephen Rothwell
2014-01-16  3:58 Stephen Rothwell
2014-01-16 12:19 ` Peter Zijlstra
2014-01-16 20:46   ` Stephen Rothwell
2014-01-16 22:25     ` Peter Zijlstra
2014-01-16 22:34       ` Stephen Rothwell
2014-01-16 22:51         ` H. Peter Anvin
2014-01-17  3:45           ` Stephen Rothwell
2014-01-18  9:46             ` Mike Galbraith
2014-01-18 12:44               ` Peter Zijlstra
2014-01-18 14:06                 ` Sabrina Dubroca
2014-01-18 15:21                 ` Mike Galbraith
2014-01-18 19:14                   ` H. Peter Anvin
2014-01-18 21:54                     ` Peter Zijlstra
2014-01-20  3:51               ` Stephen Rothwell
2014-01-20  8:42                 ` Sedat Dilek
2014-01-20  8:46                   ` Sedat Dilek
2014-01-20 13:10                     ` Stephen Rothwell
2014-01-20 15:28                       ` Sedat Dilek
2014-01-20  9:17                   ` Mike Galbraith
2014-01-20  9:25                     ` Sedat Dilek
2014-01-20  9:48                       ` Mike Galbraith
2014-01-20  4:45     ` Len Brown
2014-01-20  8:26       ` Peter Zijlstra
2014-01-20  8:56         ` H. Peter Anvin
2014-01-20  9:16           ` Peter Zijlstra
2014-01-20  9:23             ` H. Peter Anvin
2014-01-20  9:29               ` Ingo Molnar
2014-01-20 21:39                 ` Len Brown
2014-01-20 21:51                   ` Peter Zijlstra
2014-01-21  3:26                     ` Mike Galbraith
2014-01-21 10:47                     ` Ingo Molnar
2014-01-20  9:55               ` Peter Zijlstra
2014-01-20 11:00                 ` H. Peter Anvin
2014-01-20 11:05                   ` Peter Zijlstra
2014-01-16 20:56   ` H. Peter Anvin
2014-01-20  1:00 ` Len Brown
2014-01-20  1:07   ` H. Peter Anvin
2014-01-20  8:30   ` Peter Zijlstra
2014-01-20 10:13     ` Peter Zijlstra
2014-01-20 10:19       ` H. Peter Anvin
2014-01-20 11:06         ` Peter Zijlstra
2014-01-14  3:26 Stephen Rothwell
2014-01-14 14:14 ` Peter Zijlstra
2014-01-14 19:06   ` Mikulas Patocka
2014-01-14 20:05     ` Peter Zijlstra
2014-01-14 21:43       ` Mikulas Patocka
2014-01-14 22:03         ` Rafael J. Wysocki
2014-01-14 21:52           ` Mikulas Patocka
2014-01-14 22:18             ` Rafael J. Wysocki
2014-01-16 12:14         ` Peter Zijlstra
2013-10-28  9:24 Stephen Rothwell
2013-10-28 10:18 ` Thierry Reding
2013-10-28 10:26   ` Ingo Molnar
2013-10-29  6:00     ` Stephen Rothwell
2013-04-29  5:45 Stephen Rothwell
2013-02-14  2:30 Stephen Rothwell
2013-02-21  2:04 ` Stephen Rothwell
2013-02-02  5:04 Stephen Rothwell
2012-08-16  3:12 Stephen Rothwell
2012-08-16 19:46 ` Paul E. McKenney
2012-08-17  0:56   ` Stephen Rothwell
2012-08-17 11:50     ` Paul E. McKenney
2012-08-20  4:54       ` Stephen Rothwell
2012-08-20 15:09         ` Paul E. McKenney
2012-03-08  4:21 Stephen Rothwell
2012-03-08 18:00 ` Greg KH
2012-03-20 22:00   ` Stephen Rothwell
2012-03-20 22:32     ` Greg KH
2012-03-21  9:53     ` Alan Cox
2012-03-21 12:19     ` Alan Cox
2012-03-21 12:29       ` Stephen Rothwell
2012-02-24  3:47 Stephen Rothwell
2012-02-24  3:34 Stephen Rothwell
2011-10-05  6:25 Stephen Rothwell
2011-10-05  8:46 ` Peter Zijlstra
2011-10-11  6:15   ` Stephen Rothwell
2011-06-27  4:22 Stephen Rothwell
2011-06-28 10:55 ` Stijn Devriendt
2011-04-01  2:00 Stephen Rothwell
2011-01-31  4:42 Stephen Rothwell
2011-02-17  3:47 ` Stephen Rothwell
2011-02-17 13:18   ` Michal Marek
2011-02-17 15:02     ` Michal Marek
2011-02-17 17:11       ` Ingo Molnar
2011-02-17 22:47       ` Stephen Rothwell
2011-02-18  3:54         ` Stephen Rothwell
2010-10-19  5:13 Stephen Rothwell
2010-05-10  4:49 Stephen Rothwell
2010-05-10  5:09 ` H. Peter Anvin
2010-03-12  4:00 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git