Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Sedat,

On Sat, 27 Mar 2021 12:50:55 +0100 Sedat Dilek  wrote:
>
> I wonder why Stephen's fixup-patch was not carried in recent
> Linux-next releases.

It is part of the tip tree merge commit.  So it is not an explicit
commit on its own, but the needed change is there.

> Wild speculation - no random-config with x86(-64) plus CONFIG_BPF_JIT=y?

I detected it with an X86_64 allmodconfig build (which I do all day).

-- 
Cheers,
Stephen Rothwell


pgpMYBHj2tdCv.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Sedat Dilek]

On Fri, Mar 26, 2021 at 2:11 PM Borislav Petkov  wrote:
>
> On Fri, Mar 26, 2021 at 09:57:43AM +0100, Sedat Dilek wrote:
> > The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of
> > emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" is now in Linus Git
> > (see [1]).
> >
> > Where will Stephen's fixup-patch be carried?
> > Linux-next?
> > net-next?
> > ?
>
> I guess we'll resolve it on our end and pick up sfr's patch, most
> likely.
>
> Thanks for letting me know.
>

Sounds good to me.

So you need:

$ grep CONFIG_BPF_JIT= .config
1795:CONFIG_BPF_JIT=y

$ git grep CONFIG_BPF_JIT arch/x86/net/Makefile
arch/x86/net/Makefile:obj-$(CONFIG_BPF_JIT) += bpf_jit_comp32.o
arch/x86/net/Makefile:obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o

I wonder why Stephen's fixup-patch was not carried in recent
Linux-next releases.
Wild speculation - no random-config with x86(-64) plus CONFIG_BPF_JIT=y?

Anyway, I integrated Stephen's fixup-patch into my custom patchset.

$ git log --oneline --author="Stephen Rothwell" v5.12-rc4..
600417efac59 (for-5.12/x86-cpu-20210315-net-bpf-sfr) x86: fix up for
"bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for
BPF_TRAMP_F_CALL_ORIG"

Feel free to add my:

Tested-by: Sedat Dilek  # LLVM/Clang v12.0.0-rc3 (x86-64)

- Sedat -

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Fri, Mar 26, 2021 at 09:57:43AM +0100, Sedat Dilek wrote:
> The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of
> emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" is now in Linus Git
> (see [1]).
> 
> Where will Stephen's fixup-patch be carried?
> Linux-next?
> net-next?
> ?

I guess we'll resolve it on our end and pick up sfr's patch, most
likely.

Thanks for letting me know.

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Sedat Dilek]

On Mon, Mar 22, 2021 at 10:02 AM Borislav Petkov  wrote:
>
> On Mon, Mar 22, 2021 at 02:37:14PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > arch/x86/net/bpf_jit_comp.c: In function 'arch_prepare_bpf_trampoline':
> > arch/x86/net/bpf_jit_comp.c:2015:16: error: 'ideal_nops' undeclared (first 
> > use in this function)
> >  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> >   |^~
> > arch/x86/net/bpf_jit_comp.c:2015:16: note: each undeclared identifier is 
> > reported only once for each function it appears in
> > arch/x86/net/bpf_jit_comp.c:2015:27: error: 'NOP_ATOMIC5' undeclared (first 
> > use in this function); did you mean 'GFP_ATOMIC'?
> >  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> >   |   ^~~
> >   |   GFP_ATOMIC
> >
> > Caused by commit
> >
> >   a89dfde3dc3c ("x86: Remove dynamic NOP selection")
> >
> > interacting with commit
> >
> >   b90829704780 ("bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for 
> > BPF_TRAMP_F_CALL_ORIG")
> >
> > from the net tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell 
> > Date: Mon, 22 Mar 2021 14:30:37 +1100
> > Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
> >  emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG"
> >
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  arch/x86/net/bpf_jit_comp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index db50ab14df67..e2b5da5d441d 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -2012,7 +2012,7 @@ int arch_prepare_bpf_trampoline(struct 
> > bpf_tramp_image *im, void *image, void *i
> >   /* remember return value in a stack for bpf prog to access */
> >   emit_stx(, BPF_DW, BPF_REG_FP, BPF_REG_0, -8);
> >   im->ip_after_call = prog;
> > - memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> > + memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
> >   prog += X86_PATCH_SIZE;
> >   }
> >
> > --
>
> I guess we can do the same as with the hyperv tree - the folks who send the
> respective branches to Linus in the next merge window should point to this 
> patch
> of yours which Linus can apply after merging the second branch in order.
>
> Thx.
>

The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of
emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" is now in Linus Git
(see [1]).

Where will Stephen's fixup-patch be carried?
Linux-next?
net-next?
?

Thanks.

- Sedat -

[1] https://git.kernel.org/linus/b9082970478009b778aa9b22d5561eef35b53b63

Re: linux-next: build failure after merge of the tip tree

[Sedat Dilek]

On Mon, Mar 22, 2021 at 4:39 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/net/bpf_jit_comp.c: In function 'arch_prepare_bpf_trampoline':
> arch/x86/net/bpf_jit_comp.c:2015:16: error: 'ideal_nops' undeclared (first 
> use in this function)
>  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
>   |^~
> arch/x86/net/bpf_jit_comp.c:2015:16: note: each undeclared identifier is 
> reported only once for each function it appears in
> arch/x86/net/bpf_jit_comp.c:2015:27: error: 'NOP_ATOMIC5' undeclared (first 
> use in this function); did you mean 'GFP_ATOMIC'?
>  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
>   |   ^~~
>   |   GFP_ATOMIC
>
> Caused by commit
>
>   a89dfde3dc3c ("x86: Remove dynamic NOP selection")
>
> interacting with commit
>
>   b90829704780 ("bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for 
> BPF_TRAMP_F_CALL_ORIG")
>
> from the net tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell 
> Date: Mon, 22 Mar 2021 14:30:37 +1100
> Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
>  emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG"
>
> Signed-off-by: Stephen Rothwell 

I had the same issue yesterday, when I had...

 + 

...on top of Linux v5.12-rc4.
( See [1] and [2] ).

I applied the same fix.

- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/cpu=a89dfde3dc3c2dbf56910af75e2d8b11ec5308f6
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b9082970478009b778aa9b22d5561eef35b53b63

> ---
>  arch/x86/net/bpf_jit_comp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index db50ab14df67..e2b5da5d441d 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -2012,7 +2012,7 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image 
> *im, void *image, void *i
> /* remember return value in a stack for bpf prog to access */
> emit_stx(, BPF_DW, BPF_REG_FP, BPF_REG_0, -8);
> im->ip_after_call = prog;
> -   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> +   memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
> prog += X86_PATCH_SIZE;
> }
>
> --
> 2.30.0
>
> --
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Mon, Mar 22, 2021 at 02:37:14PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/net/bpf_jit_comp.c: In function 'arch_prepare_bpf_trampoline':
> arch/x86/net/bpf_jit_comp.c:2015:16: error: 'ideal_nops' undeclared (first 
> use in this function)
>  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
>   |^~
> arch/x86/net/bpf_jit_comp.c:2015:16: note: each undeclared identifier is 
> reported only once for each function it appears in
> arch/x86/net/bpf_jit_comp.c:2015:27: error: 'NOP_ATOMIC5' undeclared (first 
> use in this function); did you mean 'GFP_ATOMIC'?
>  2015 |   memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
>   |   ^~~
>   |   GFP_ATOMIC
> 
> Caused by commit
> 
>   a89dfde3dc3c ("x86: Remove dynamic NOP selection")
> 
> interacting with commit
> 
>   b90829704780 ("bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for 
> BPF_TRAMP_F_CALL_ORIG")
> 
> from the net tree.
> 
> I have applied the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Mon, 22 Mar 2021 14:30:37 +1100
> Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
>  emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/x86/net/bpf_jit_comp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index db50ab14df67..e2b5da5d441d 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -2012,7 +2012,7 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image 
> *im, void *image, void *i
>   /* remember return value in a stack for bpf prog to access */
>   emit_stx(, BPF_DW, BPF_REG_FP, BPF_REG_0, -8);
>   im->ip_after_call = prog;
> - memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> + memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
>   prog += X86_PATCH_SIZE;
>   }
>  
> -- 

I guess we can do the same as with the hyperv tree - the folks who send the
respective branches to Linus in the next merge window should point to this patch
of yours which Linus can apply after merging the second branch in order.

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 17 Mar 2021 21:04:08 +0100 Ingo Molnar  wrote:
>
> * Borislav Petkov  wrote:
> 
> > On Thu, Mar 18, 2021 at 05:49:21AM +1100, Stephen Rothwell wrote:  
> > > That fixes the powerpc build for me, thanks.  
> > 
> > Thx, adding your Tested-by and pushing out.  
> 
> I've pushed this out into tip:auto-latest as well, so that tomorrow's 
> -next should pick this up automatically. (Assuming everything else is 
> fine.)

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Thu, Mar 18, 2021 at 05:49:21AM +1100, Stephen Rothwell wrote:
> > That fixes the powerpc build for me, thanks.
> 
> Thx, adding your Tested-by and pushing out.

I've pushed this out into tip:auto-latest as well, so that tomorrow's 
-next should pick this up automatically. (Assuming everything else is 
fine.)

Thanks,

Ingo

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Thu, Mar 18, 2021 at 05:49:21AM +1100, Stephen Rothwell wrote:
> That fixes the powerpc build for me, thanks.

Thx, adding your Tested-by and pushing out.

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Borislav,

On Wed, 17 Mar 2021 19:02:36 +0100 Borislav Petkov  wrote:
>
> On Wed, Mar 17, 2021 at 09:22:15AM -0700, Ian Rogers wrote:
> > The  path also needs fixing. With the following
> > I was able to build for arm64 and powerpc.  
> 
> Thanks, I've updated and added your Tested-by. I'll give sfr a chance to
> test and queue it tomorrow.
> 
> ---
> From d242b2639a23ed03d9aed94cf05b99af5343d4e9 Mon Sep 17 00:00:00 2001
> From: Borislav Petkov 
> Date: Wed, 17 Mar 2021 11:33:04 +0100
> Subject: [PATCH] tools/insn: Restore the relative include paths for cross 
> building
> 
> Building perf on ppc causes:
> 
>   In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
>   util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
> asm/inat.h: No such file or directory
>  14 | #include  /*__ignore_sync_check__ */
> |  ^~~~
> 
> Restore the relative include paths so that the compiler can find the
> headers.
> 
> Fixes: 93281c4a9657 ("x86/insn: Add an insn_decode() API")
> Reported-by: Ian Rogers 
> Reported-by: Stephen Rothwell 
> Signed-off-by: Borislav Petkov 
> Tested-by: Ian Rogers 
> ---
>  tools/arch/x86/lib/insn.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c
> index cd4dedde3265..c41f95815480 100644
> --- a/tools/arch/x86/lib/insn.c
> +++ b/tools/arch/x86/lib/insn.c
> @@ -11,13 +11,13 @@
>  #else
>  #include 
>  #endif
> -#include  /*__ignore_sync_check__ */
> -#include  /* __ignore_sync_check__ */
> +#include "../include/asm/inat.h" /* __ignore_sync_check__ */
> +#include "../include/asm/insn.h" /* __ignore_sync_check__ */
>  
>  #include 
>  #include 
>  
> -#include  /* __ignore_sync_check__ */
> +#include "../include/asm/emulate_prefix.h" /* __ignore_sync_check__ */
>  
>  #define leXX_to_cpu(t, r)\
>  ({   \
> -- 
> 2.29.2

That fixes the powerpc build for me, thanks.
-- 
Cheers,
Stephen Rothwell


pgpj3EUw42BWy.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Wed, Mar 17, 2021 at 09:22:15AM -0700, Ian Rogers wrote:
> The  path also needs fixing. With the following
> I was able to build for arm64 and powerpc.

Thanks, I've updated and added your Tested-by. I'll give sfr a chance to
test and queue it tomorrow.

---
>From d242b2639a23ed03d9aed94cf05b99af5343d4e9 Mon Sep 17 00:00:00 2001
From: Borislav Petkov 
Date: Wed, 17 Mar 2021 11:33:04 +0100
Subject: [PATCH] tools/insn: Restore the relative include paths for cross 
building

Building perf on ppc causes:

  In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
  util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
asm/inat.h: No such file or directory
 14 | #include  /*__ignore_sync_check__ */
|  ^~~~

Restore the relative include paths so that the compiler can find the
headers.

Fixes: 93281c4a9657 ("x86/insn: Add an insn_decode() API")
Reported-by: Ian Rogers 
Reported-by: Stephen Rothwell 
Signed-off-by: Borislav Petkov 
Tested-by: Ian Rogers 
---
 tools/arch/x86/lib/insn.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c
index cd4dedde3265..c41f95815480 100644
--- a/tools/arch/x86/lib/insn.c
+++ b/tools/arch/x86/lib/insn.c
@@ -11,13 +11,13 @@
 #else
 #include 
 #endif
-#include  /*__ignore_sync_check__ */
-#include  /* __ignore_sync_check__ */
+#include "../include/asm/inat.h" /* __ignore_sync_check__ */
+#include "../include/asm/insn.h" /* __ignore_sync_check__ */
 
 #include 
 #include 
 
-#include  /* __ignore_sync_check__ */
+#include "../include/asm/emulate_prefix.h" /* __ignore_sync_check__ */
 
 #define leXX_to_cpu(t, r)  \
 ({ \
-- 
2.29.2

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Ian Rogers]

On Wed, Mar 17, 2021 at 3:54 AM Borislav Petkov  wrote:
>
> + Ian.
>
> On Wed, Mar 17, 2021 at 03:08:58PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (native perf)
> > failed like this:
> >
> > In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
> > util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
> > asm/inat.h: No such file or directory
> >14 | #include  /*__ignore_sync_check__ */
> >   |  ^~~~
> >
> > This is a powerpc build of perf.  I can't see what caused this failure,
> > so I have used the version of the tip tree from next-20210316 for today.
>
> Yah, this has come up in the past during review but the wrong version
> somehow snuck in, sorry. ;-\
>
> Can you guys verify this fixes the build issue? I don't have a ppc build
> setup.
>
> Thx.

The  path also needs fixing. With the following
I was able to build for arm64 and powerpc.

Thanks,
Ian

diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c
index cd4dedde3265..968360bf2150 100644
--- a/tools/arch/x86/lib/insn.c
+++ b/tools/arch/x86/lib/insn.c
@@ -11,13 +11,13 @@
 #else
 #include 
 #endif
-#include  /*__ignore_sync_check__ */
-#include  /* __ignore_sync_check__ */
+#include "../include/asm/inat.h" /*__ignore_sync_check__ */
+#include "../include/asm/insn.h" /* __ignore_sync_check__ */

 #include 
 #include 

-#include  /* __ignore_sync_check__ */
+#include "../include/asm/emulate_prefix.h" /* __ignore_sync_check__ */

 #define leXX_to_cpu(t, r)  \
 ({ \

> ---
> From 50d91054fc421e2a90923706d5ca79e941e28300 Mon Sep 17 00:00:00 2001
> From: Borislav Petkov 
> Date: Wed, 17 Mar 2021 11:33:04 +0100
> Subject: [PATCH] tools/insn: Restore the relative include paths for cross
>  building
>
> Building perf on ppc causes:
>
>   In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
>   util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
> asm/inat.h: No such file or directory
>  14 | #include  /*__ignore_sync_check__ */
> |  ^~~~
>
> Restore the relative include paths so that the compiler can find the
> headers.
>
> Fixes: 93281c4a9657 ("x86/insn: Add an insn_decode() API")
> Reported-by: Ian Rogers 
> Reported-by: Stephen Rothwell 
> NOT-Signed-off-by: Borislav Petkov 
> ---
>  tools/arch/x86/lib/insn.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c
> index cd4dedde3265..999fbd4c9bea 100644
> --- a/tools/arch/x86/lib/insn.c
> +++ b/tools/arch/x86/lib/insn.c
> @@ -11,8 +11,8 @@
>  #else
>  #include 
>  #endif
> -#include  /*__ignore_sync_check__ */
> -#include  /* __ignore_sync_check__ */
> +#include "../include/asm/inat.h" /* __ignore_sync_check__ */
> +#include "../include/asm/insn.h" /* __ignore_sync_check__ */
>
>  #include 
>  #include 
> --
> 2.29.2
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG 
> Nürnberg

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

+ Ian.

On Wed, Mar 17, 2021 at 03:08:58PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (native perf)
> failed like this:
> 
> In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
> util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
> asm/inat.h: No such file or directory
>14 | #include  /*__ignore_sync_check__ */
>   |  ^~~~
> 
> This is a powerpc build of perf.  I can't see what caused this failure,
> so I have used the version of the tip tree from next-20210316 for today.

Yah, this has come up in the past during review but the wrong version
somehow snuck in, sorry. ;-\

Can you guys verify this fixes the build issue? I don't have a ppc build
setup.

Thx.

---
>From 50d91054fc421e2a90923706d5ca79e941e28300 Mon Sep 17 00:00:00 2001
From: Borislav Petkov 
Date: Wed, 17 Mar 2021 11:33:04 +0100
Subject: [PATCH] tools/insn: Restore the relative include paths for cross
 building

Building perf on ppc causes:

  In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15:
  util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: 
asm/inat.h: No such file or directory
 14 | #include  /*__ignore_sync_check__ */
|  ^~~~

Restore the relative include paths so that the compiler can find the
headers.

Fixes: 93281c4a9657 ("x86/insn: Add an insn_decode() API")
Reported-by: Ian Rogers 
Reported-by: Stephen Rothwell 
NOT-Signed-off-by: Borislav Petkov 
---
 tools/arch/x86/lib/insn.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c
index cd4dedde3265..999fbd4c9bea 100644
--- a/tools/arch/x86/lib/insn.c
+++ b/tools/arch/x86/lib/insn.c
@@ -11,8 +11,8 @@
 #else
 #include 
 #endif
-#include  /*__ignore_sync_check__ */
-#include  /* __ignore_sync_check__ */
+#include "../include/asm/inat.h" /* __ignore_sync_check__ */
+#include "../include/asm/insn.h" /* __ignore_sync_check__ */
 
 #include 
 #include 
-- 
2.29.2

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Peter,

On Wed, 3 Mar 2021 10:44:32 +0100 Peter Zijlstra  wrote:
>
> Damn, sorry about that. I've rebased tip/sched/core and all should be
> well now.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell


pgpxZzQ5s2EcR.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Wed, Mar 03, 2021 at 10:38:42AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from drivers/usb/usbip/usbip_common.c:18:
> drivers/usb/usbip/usbip_common.h: In function 'usbip_kcov_handle_init':
> drivers/usb/usbip/usbip_common.h:348:20: error: implicit declaration of 
> function 'kcov_common_handle' [-Werror=implicit-function-declaration]
>   348 |  ud->kcov_handle = kcov_common_handle();
>   |^~
> drivers/usb/usbip/usbip_common.h: In function 'usbip_kcov_remote_start':
> drivers/usb/usbip/usbip_common.h:353:2: error: implicit declaration of 
> function 'kcov_remote_start_common' [-Werror=implicit-function-declaration]
>   353 |  kcov_remote_start_common(ud->kcov_handle);
>   |  ^~~~
> drivers/usb/usbip/usbip_common.h: In function 'usbip_kcov_remote_stop':
> drivers/usb/usbip/usbip_common.h:358:2: error: implicit declaration of 
> function 'kcov_remote_stop'; did you mean 'usbip_kcov_remote_stop'? 
> [-Werror=implicit-function-declaration]
>   358 |  kcov_remote_stop();
>   |  ^~~~
>   |  usbip_kcov_remote_stop
> 
> Caused by commit
> 
>   eae7a59d5a1e ("kcov: Remove kcov include from sched.h and move it to its 
> users.")
> 
> I have used the tip tree from next-20210302 for today.

Damn, sorry about that. I've rebased tip/sched/core and all should be
well now.

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Thu, Jan 14, 2021 at 03:11:45PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> arch/x86/kernel/cpu/amd.c: In function 'bsp_init_amd':
> arch/x86/kernel/cpu/amd.c:545:3: error: '__max_die_per_package' undeclared 
> (first use in this function); did you mean 'topology_max_die_per_package'?

Yah, the *one* time I forget to run randconfig builds... :-\

Thanks for reporting, fix coming up...

-- 
Regards/Gruss,
Boris.

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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> kernel/smp.c: In function 'csd_lock_wait_getcpu':
> kernel/smp.c:133:13: error: 'call_single_data_t' {aka 'struct 
> __call_single_data'} has no member named 'dst'
>   133 |   return csd->dst; /* Other CSD_TYPE_ values might not have ->dst. */
>   | ^~
> 
> Caused by commit
> 
>   545b8c8df41f ("smp: Cleanup smp_call_function*()")

Inded, I just (belatedly) noticed this semantic merge conflict with 
upstream too, I resolved it in tip:sched/core and it should be all sorted 
out by tomorrow's -next integration. Sorry about this!

Thanks,

Ingo

Re: linux-next: build failure after merge of the tip tree

[Vasily Gorbik]

On Fri, Oct 09, 2020 at 03:28:46PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> In file included from tools/include/linux/build_bug.h:5,
>  from tools/include/linux/kernel.h:8,
>  from util/intel-pt-decoder/intel-pt-insn-decoder.c:7:
> util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function 
> '__insn_get_emulate_prefix':
> tools/include/linux/compiler.h:37:38: error: nested extern declaration of 
> '__compiletime_assert_0' [-Werror=nested-externs]
>37 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
> __COUNTER__)
>   |  ^
...snip...
> 
> Caused by commit
> 
>   2a522b53c470 ("x86/insn: Support big endian cross-compiles")
> 
> I have reverted commits
> 
> a23b701ae9b3 objtool: Rework header include paths
> 1b4998c364bc objtool: Fix x86 orc generation on big endian cross compiles
> 317664a7fcc9 objtool: Fix reloc generation on big endian cross compiles
> 2a522b53c470 x86/insn: Support big endian cross-compiles
> 2486baae2cf6 objtool: Allow nested externs to enable BUILD_BUG()
> 
> for today.
> 
> This is a PowerPC LE native build of tools/perf.

Oh, I missed that. Sorry about that. Obviously x86 instruction
decoder is also used in perf. The question is, should we just disable
-Wnested-externs for perf like we did for the objtool. Or since we got
BUILD_BUG() implementation in tools simply disable -Wnested-externs for
all tools altogether? By throwing it out of EXTRA_WARNINGS.

Vasily Gorbik (1):
  perf build: Allow nested externs to enable BUILD_BUG() usage

 tools/perf/Makefile.config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿

Re: linux-next: build failure after merge of the tip tree

[peterz]

On Tue, Sep 08, 2020 at 07:12:23PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> ERROR: modpost: too long symbol 
> ".__tracepoint_iter_pnfs_mds_fallback_pg_get_mirror_count" 
> [fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko]
> 
> Caused by commit
> 
>   d25e37d89dd2 ("tracepoint: Optimize using static_call()")
> 
> Exported symbols need to be <= (64 - sizeof(Elf_Addr)) long.  This is
> presumably 56 on 64 bit arches and the above symbol (including the '.')
> is 56 characters long.

I suppose something like the below ought to cure that. Still, stupid
long tracename that.

---

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 3722a10fc46d..81fa0b2f271e 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -154,7 +154,7 @@ static inline struct tracepoint 
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
 #ifdef CONFIG_HAVE_STATIC_CALL
 #define __DO_TRACE_CALL(name)  static_call(tp_func_##name)
 #else
-#define __DO_TRACE_CALL(name)  __tracepoint_iter_##name
+#define __DO_TRACE_CALL(name)  __traceiter_##name
 #endif /* CONFIG_HAVE_STATIC_CALL */
 
 /*
@@ -232,8 +232,8 @@ static inline struct tracepoint 
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * poking RCU a bit.
  */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
-   extern int __tracepoint_iter_##name(data_proto);\
-   DECLARE_STATIC_CALL(tp_func_##name, __tracepoint_iter_##name); \
+   extern int __traceiter_##name(data_proto);  \
+   DECLARE_STATIC_CALL(tp_func_##name, __traceiter_##name);\
extern struct tracepoint __tracepoint_##name;   \
static inline void trace_##name(proto)  \
{   \
@@ -288,19 +288,19 @@ static inline struct tracepoint 
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
static const char __tpstrtab_##_name[]  \
__section(__tracepoints_strings) = #_name;  \
extern struct static_call_key STATIC_CALL_KEY(tp_func_##_name); \
-   int __tracepoint_iter_##_name(void *__data, proto); \
+   int __traceiter_##_name(void *__data, proto);   \
struct tracepoint __tracepoint_##_name  __used  \
__section(__tracepoints) = {\
.name = __tpstrtab_##_name, \
.key = STATIC_KEY_INIT_FALSE,   \
.static_call_key = _CALL_KEY(tp_func_##_name),   \
.static_call_tramp = STATIC_CALL_TRAMP_ADDR(tp_func_##_name), \
-   .iterator = &__tracepoint_iter_##_name, \
+   .iterator = &__traceiter_##_name,   \
.regfunc = _reg,\
.unregfunc = _unreg,\
.funcs = NULL };\
__TRACEPOINT_ENTRY(_name);  \
-   int __tracepoint_iter_##_name(void *__data, proto)  \
+   int __traceiter_##_name(void *__data, proto)\
{   \
struct tracepoint_func *it_func_ptr;\
void *it_func;  \
@@ -314,18 +314,18 @@ static inline struct tracepoint 
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
} while ((++it_func_ptr)->func);\
return 0;   \
}   \
-   DEFINE_STATIC_CALL(tp_func_##_name, __tracepoint_iter_##_name);
+   DEFINE_STATIC_CALL(tp_func_##_name, __traceiter_##_name);
 
 #define DEFINE_TRACE(name, proto, args)\
DEFINE_TRACE_FN(name, NULL, NULL, PARAMS(proto), PARAMS(args));
 
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name) \
EXPORT_SYMBOL_GPL(__tracepoint_##name); \
-   EXPORT_SYMBOL_GPL(__tracepoint_iter_##name);\
+   EXPORT_SYMBOL_GPL(__traceiter_##name);  \
EXPORT_STATIC_CALL_GPL(tp_func_##name)
 #define EXPORT_TRACEPOINT_SYMBOL(name) \
EXPORT_SYMBOL(__tracepoint_##name); \
-   EXPORT_SYMBOL(__tracepoint_iter_##name);\
+   EXPORT_SYMBOL(__traceiter_##name);  \
EXPORT_STATIC_CALL(tp_func_##name)
 
 

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Thu, 3 Sep 2020 05:51:08 +0200 Ingo Molnar  wrote:
>
> I've merged the old commit by mistake - it's removed now.

Ah, OK, thanks.

-- 
Cheers,
Stephen Rothwell


pgpqbzuw8G3mY.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> 
> Caused by commit
> 
>   f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")
> 
> interacting with commit
> 
>   a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
> 
> from Linus' tree (v5.7-rc6) - the automatic merge did not go well.
> 
> I have added this patch for today (it removes the older version).
> 
> From: Stephen Rothwell 
> Date: Thu, 3 Sep 2020 12:31:13 +1000
> Subject: [PATCH] merge fix for compiler.h

I've merged the old commit by mistake - it's removed now.

Thanks,

Ingo

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Fri, 31 Jul 2020 11:57:35 +0200 Ingo Molnar  wrote:
>
> I've merged Linus's latest into tip:locking/core, keeping the simpler 
> solution of a6342915881a and reducing the dependency hell.
> 
> Will push it all out hopefully later today (unrelated changes need 
> more testing), from that point on there should be no conflict in 
> -next.
> 
> My plan would be to send that resolution to Linus, under the 
> assumption that a6342915881a is superior to the upstream aa54ea903abb 
> solution.

Sounds good to me, thanks.

(though, no rush on my account as I won't do another linux-next until
Monday)
-- 
Cheers,
Stephen Rothwell


pgp4xw5t62YYh.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/asm-generic/getorder.h:8,
>  from arch/arm/include/asm/page.h:166,
>  from arch/arm/include/asm/thread_info.h:14,
>  from arch/arm/include/asm/percpu.h:16,
>  from include/linux/irqflags.h:17,
>  from arch/arm/include/asm/bitops.h:28,
>  from include/linux/bitops.h:29,
>  from include/linux/kernel.h:12,
>  from include/asm-generic/bug.h:20,
>  from arch/arm/include/asm/bug.h:60,
>  from include/linux/bug.h:5,
>  from include/linux/page-flags.h:10,
>  from kernel/bounds.c:10:
> include/linux/log2.h: In function '__ilog2_u32':
> include/linux/log2.h:24:9: error: implicit declaration of function 'fls' 
> [-Werror=implicit-function-declaration]
>24 |  return fls(n) - 1;
>   | ^~~
> 
> And so on ...
> 
> Caused by commit
> 
>   a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu 
> variables")
> 
> interacting with commit
> 
>   00a30a5c9e6b ("arm: include asm/thread_info.h in asm/percpu.h")
> 
> (which was a fix of mine but now the equivalent is in Linus' tree as commit
> 
>   aa54ea903abb ("ARM: percpu.h: fix build error")
> )
> 
> I have reverted 00a30a5c9e6b since commit
> 
>   a6342915881a ("arm: Break cyclic percpu include")
> 
> (which precedes a21ee6055c30) acomplishes the same thing differently.
> Something will be required when this is merged with Linus' tree, though.

I've merged Linus's latest into tip:locking/core, keeping the simpler 
solution of a6342915881a and reducing the dependency hell.

Will push it all out hopefully later today (unrelated changes need 
more testing), from that point on there should be no conflict in 
-next.

My plan would be to send that resolution to Linus, under the 
assumption that a6342915881a is superior to the upstream aa54ea903abb 
solution.

Thanks,

Ingo

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 14 Jul 2020 13:50:12 +1000 Stephen Rothwell  
wrote:
>
> On Tue, 7 Jul 2020 12:33:01 +1000 Stephen Rothwell  
> wrote:
> >
> > On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell  
> > wrote:  
> > >
> > > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell 
> > >  wrote:
> > > >
> > > > After merging the tip tree, today's linux-next build (x86_64 
> > > > allmodconfig)
> > > > failed like this:
> > > > 
> > > > ERROR: modpost: "sched_setscheduler" 
> > > > [kernel/trace/ring_buffer_benchmark.ko] undefined!
> > > > 
> > > > Caused by commit
> > > > 
> > > >   616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
> > > > 
> > > > Missed one :-)
> > > > 
> > > > I have reverted that commit for today.  
> > > 
> > > I am still reverting that commit.
> > 
> > Ditto ...  
> 
> Ping?

OK, it has now been three weeks ... I must admit I was a little
suprised that initial testing of the tip tree (or even the branch that
this commit is on) did not pick this up.

Unless there is something really weird going on here, Linus will notice
if you try to get him to pull this as he tests with an x86_64
allmodconfig build.

-- 
Cheers,
Stephen Rothwell


pgpGW7Zgy2vol.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 7 Jul 2020 12:33:01 +1000 Stephen Rothwell  
wrote:
>
> On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell  
> > wrote:  
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > ERROR: modpost: "sched_setscheduler" 
> > > [kernel/trace/ring_buffer_benchmark.ko] undefined!
> > > 
> > > Caused by commit
> > > 
> > >   616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
> > > 
> > > Missed one :-)
> > > 
> > > I have reverted that commit for today.
> > 
> > I am still reverting that commit.  
> 
> Ditto ...

Ping?
-- 
Cheers,
Stephen Rothwell


pgpf3TYnStxJt.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > ERROR: modpost: "sched_setscheduler" 
> > [kernel/trace/ring_buffer_benchmark.ko] undefined!
> > 
> > Caused by commit
> > 
> >   616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
> > 
> > Missed one :-)
> > 
> > I have reverted that commit for today.  
> 
> I am still reverting that commit.

Ditto ...

-- 
Cheers,
Stephen Rothwell


pgpUPnKm6pNic.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell  
wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: modpost: "sched_setscheduler" [kernel/trace/ring_buffer_benchmark.ko] 
> undefined!
> 
> Caused by commit
> 
>   616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
> 
> Missed one :-)
> 
> I have reverted that commit for today.

I am still reverting that commit.
-- 
Cheers,
Stephen Rothwell


pgpmM2wCmyHSz.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Borislav,

On Sun, 21 Jun 2020 12:53:50 +0200 Borislav Petkov  wrote:
>
> + acme for an FYI.
> 
> On Sun, Jun 21, 2020 at 04:33:23PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > In file included from trace/beauty/tracepoints/x86_msr.c:10:
> > perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error: 
> > initialized field overwritten [-Werror=override-init]
> >   292 |  [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
> >   | ^~~
> > perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near 
> > initialization for 'x86_AMD_V_KVM_MSRs[640]')
> > 
> > Caused by commit
> > 
> >   1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> > 
> > I have used the tip tree from next-20200618 for tooday.  
> 
> Thanks, I saw that once but then got distracted to something of higher
> prio. :-\
> 
> I'll apply this after testing it a bit:
> 
> ---
> From: Borislav Petkov 
> Date: Sun, 21 Jun 2020 12:41:53 +0200
> Subject: [PATCH] x86/msr: Move the F15h MSRs where they belong
> 
> 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> 
> moved the three F15h power MSRs to the architectural list but that was
> wrong as they belong in the family 0x15 list. That also caused:
> 
>   In file included from trace/beauty/tracepoints/x86_msr.c:10:
>   perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error: 
> initialized field overwritten [-Werror=override-init]
> 292 |  [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
> | ^~~
>   perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near 
> initialization for 'x86_AMD_V_KVM_MSRs[640]')
> 
> due to MSR_F15H_PTSC ending up being defined twice. Move them where they
> belong and drop the duplicate.
> 
> While at it, update the msr-index.h copy to pick up the changes from
> 
>   7e5b3c267d25 ("x86/speculation: Add Special Register Buffer Data Sampling 
> (SRBDS) mitigation")
> 
> Fixes: 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> Reported-by: Stephen Rothwell 
> Signed-off-by: Borislav Petkov 
> ---
>  arch/x86/include/asm/msr-index.h   | 5 ++---
>  tools/arch/x86/include/asm/msr-index.h | 9 ++---
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr-index.h 
> b/arch/x86/include/asm/msr-index.h
> index eb9537254920..63ed8fe35738 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -422,11 +422,8 @@
>  #define MSR_AMD_PERF_CTL 0xc0010062
>  #define MSR_AMD_PERF_STATUS  0xc0010063
>  #define MSR_AMD_PSTATE_DEF_BASE  0xc0010064
> -#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> -#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
>  #define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
>  #define MSR_AMD64_OSVW_STATUS0xc0010141
> -#define MSR_F15H_PTSC0xc0010280
>  #define MSR_AMD_PPIN_CTL 0xc00102f0
>  #define MSR_AMD_PPIN 0xc00102f1
>  #define MSR_AMD64_CPUID_FN_1 0xc0011004
> @@ -469,6 +466,8 @@
>  #define MSR_F16H_DR0_ADDR_MASK   0xc0011027
>  
>  /* Fam 15h MSRs */
> +#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> +#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
>  #define MSR_F15H_PERF_CTL0xc0010200
>  #define MSR_F15H_PERF_CTL0   MSR_F15H_PERF_CTL
>  #define MSR_F15H_PERF_CTL1   (MSR_F15H_PERF_CTL + 2)
> diff --git a/tools/arch/x86/include/asm/msr-index.h 
> b/tools/arch/x86/include/asm/msr-index.h
> index 7dfd45bb6cdb..63ed8fe35738 100644
> --- a/tools/arch/x86/include/asm/msr-index.h
> +++ b/tools/arch/x86/include/asm/msr-index.h
> @@ -128,6 +128,10 @@
>  #define TSX_CTRL_RTM_DISABLE BIT(0)  /* Disable RTM feature */
>  #define TSX_CTRL_CPUID_CLEAR BIT(1)  /* Disable TSX enumeration */
>  
> +/* SRBDS support */
> +#define MSR_IA32_MCU_OPT_CTRL0x0123
> +#define RNGDS_MITG_DIS   BIT(0)
> +
>  #define MSR_IA32_SYSENTER_CS 0x0174
>  #define MSR_IA32_SYSENTER_ESP0x0175
>  #define MSR_IA32_SYSENTER_EIP0x0176
> @@ -418,11 +422,8 @@
>  #define MSR_AMD_PERF_CTL 0xc0010062
>  #define MSR_AMD_PERF_STATUS  0xc0010063
>  #define MSR_AMD_PSTATE_DEF_BASE  0xc0010064
> -#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> -#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
>  #define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
>  #define MSR_AMD64_OSVW_STATUS0xc0010141
> -#define MSR_F15H_PTSC0xc0010280
>  #define MSR_AMD_PPIN_CTL 0xc00102f0
>  #define MSR_AMD_PPIN 0xc00102f1
>  #define MSR_AMD64_CPUID_FN_1 0xc0011004
> 

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

+ acme for an FYI.

On Sun, Jun 21, 2020 at 04:33:23PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> In file included from trace/beauty/tracepoints/x86_msr.c:10:
> perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error: initialized 
> field overwritten [-Werror=override-init]
>   292 |  [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
>   | ^~~
> perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near 
> initialization for 'x86_AMD_V_KVM_MSRs[640]')
> 
> Caused by commit
> 
>   1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> 
> I have used the tip tree from next-20200618 for tooday.

Thanks, I saw that once but then got distracted to something of higher
prio. :-\

I'll apply this after testing it a bit:

---
From: Borislav Petkov 
Date: Sun, 21 Jun 2020 12:41:53 +0200
Subject: [PATCH] x86/msr: Move the F15h MSRs where they belong

1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")

moved the three F15h power MSRs to the architectural list but that was
wrong as they belong in the family 0x15 list. That also caused:

  In file included from trace/beauty/tracepoints/x86_msr.c:10:
  perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error: initialized 
field overwritten [-Werror=override-init]
292 |  [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
| ^~~
  perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near 
initialization for 'x86_AMD_V_KVM_MSRs[640]')

due to MSR_F15H_PTSC ending up being defined twice. Move them where they
belong and drop the duplicate.

While at it, update the msr-index.h copy to pick up the changes from

  7e5b3c267d25 ("x86/speculation: Add Special Register Buffer Data Sampling 
(SRBDS) mitigation")

Fixes: 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
Reported-by: Stephen Rothwell 
Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/msr-index.h   | 5 ++---
 tools/arch/x86/include/asm/msr-index.h | 9 ++---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index eb9537254920..63ed8fe35738 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -422,11 +422,8 @@
 #define MSR_AMD_PERF_CTL   0xc0010062
 #define MSR_AMD_PERF_STATUS0xc0010063
 #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
-#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
-#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
 #define MSR_AMD64_OSVW_ID_LENGTH   0xc0010140
 #define MSR_AMD64_OSVW_STATUS  0xc0010141
-#define MSR_F15H_PTSC  0xc0010280
 #define MSR_AMD_PPIN_CTL   0xc00102f0
 #define MSR_AMD_PPIN   0xc00102f1
 #define MSR_AMD64_CPUID_FN_1   0xc0011004
@@ -469,6 +466,8 @@
 #define MSR_F16H_DR0_ADDR_MASK 0xc0011027
 
 /* Fam 15h MSRs */
+#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
+#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
 #define MSR_F15H_PERF_CTL  0xc0010200
 #define MSR_F15H_PERF_CTL0 MSR_F15H_PERF_CTL
 #define MSR_F15H_PERF_CTL1 (MSR_F15H_PERF_CTL + 2)
diff --git a/tools/arch/x86/include/asm/msr-index.h 
b/tools/arch/x86/include/asm/msr-index.h
index 7dfd45bb6cdb..63ed8fe35738 100644
--- a/tools/arch/x86/include/asm/msr-index.h
+++ b/tools/arch/x86/include/asm/msr-index.h
@@ -128,6 +128,10 @@
 #define TSX_CTRL_RTM_DISABLE   BIT(0)  /* Disable RTM feature */
 #define TSX_CTRL_CPUID_CLEAR   BIT(1)  /* Disable TSX enumeration */
 
+/* SRBDS support */
+#define MSR_IA32_MCU_OPT_CTRL  0x0123
+#define RNGDS_MITG_DIS BIT(0)
+
 #define MSR_IA32_SYSENTER_CS   0x0174
 #define MSR_IA32_SYSENTER_ESP  0x0175
 #define MSR_IA32_SYSENTER_EIP  0x0176
@@ -418,11 +422,8 @@
 #define MSR_AMD_PERF_CTL   0xc0010062
 #define MSR_AMD_PERF_STATUS0xc0010063
 #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
-#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
-#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
 #define MSR_AMD64_OSVW_ID_LENGTH   0xc0010140
 #define MSR_AMD64_OSVW_STATUS  0xc0010141
-#define MSR_F15H_PTSC  0xc0010280
 #define MSR_AMD_PPIN_CTL   0xc00102f0
 #define MSR_AMD_PPIN   0xc00102f1
 #define MSR_AMD64_CPUID_FN_1   0xc0011004
@@ -465,6 +466,8 @@
 #define MSR_F16H_DR0_ADDR_MASK 0xc0011027
 
 /* Fam 15h MSRs */
+#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
+#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
 #define MSR_F15H_PERF_CTL  0xc0010200
 #define MSR_F15H_PERF_CTL0 MSR_F15H_PERF_CTL
 #define 

Re: linux-next: build failure after merge of the tip tree

[Paul E. McKenney]

On Mon, May 25, 2020 at 10:20:29AM +0200, Marco Elver wrote:
> On Mon, 25 May 2020 at 02:37, Paul E. McKenney  wrote:
> >
> > On Sat, May 23, 2020 at 02:23:45PM -0700, Paul E. McKenney wrote:
> > > On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> > > > "Paul E. McKenney"  writes:
> > > > > On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> > > > >> core/rcu is the one which diverged and caused the merge conflict with
> > > > >> PPC to happen twice. So Paul needs to remove the stale core/rcu bits 
> > > > >> and
> > > > >> rebase on the current version (which is not going to change again).
> > > > >
> > > > > So there will be another noinstr-rcu-* tag, and I will rebase on top
> > > > > of that, correct?  If so, fair enough!
> > > >
> > > > Here you go: noinstr-rcu-220-05-23
> > > >
> > > > I wanted this to be 2020 and not 220 but I noticed after pushing it
> > > > out. I guess it still does the job :)
> > >
> > > Now -that- is what I call an old-school tag name!!!  ;-)
> > >
> > > I remerged, rebased, and pushed to -rcu branch "dev".
> > >
> > > If it survives testing, I will reset -rcu branch "rcu/next" as well.
> >
> > And passed!  The compile times are back to their old selves on my
> > laptop as well.
> >
> > Thank you for setting this up, Thomas!!!
> 
> I just noticed that -rcu and -tip both still have their own version of
> "ubsan, kcsan: Don't combine sanitizer with kcov on clang". For there
> to not be any conflicts in -next, "ubsan, kcsan: Don't combine
> sanitizer with kcov on clang" could be dropped from -rcu.

Thank you for spotting this!  Yes, if it is already in -tip, I should
drop it.  If this causes trouble for clang users working with -rcu, I
can always pull in the exact commit used in -tip.

Anyway, -rcu branch "dev" no longer contains this commit.

Thanx, Paul

Re: linux-next: build failure after merge of the tip tree

[Marco Elver]

On Mon, 25 May 2020 at 02:37, Paul E. McKenney  wrote:
>
> On Sat, May 23, 2020 at 02:23:45PM -0700, Paul E. McKenney wrote:
> > On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> > > "Paul E. McKenney"  writes:
> > > > On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> > > >> core/rcu is the one which diverged and caused the merge conflict with
> > > >> PPC to happen twice. So Paul needs to remove the stale core/rcu bits 
> > > >> and
> > > >> rebase on the current version (which is not going to change again).
> > > >
> > > > So there will be another noinstr-rcu-* tag, and I will rebase on top
> > > > of that, correct?  If so, fair enough!
> > >
> > > Here you go: noinstr-rcu-220-05-23
> > >
> > > I wanted this to be 2020 and not 220 but I noticed after pushing it
> > > out. I guess it still does the job :)
> >
> > Now -that- is what I call an old-school tag name!!!  ;-)
> >
> > I remerged, rebased, and pushed to -rcu branch "dev".
> >
> > If it survives testing, I will reset -rcu branch "rcu/next" as well.
>
> And passed!  The compile times are back to their old selves on my
> laptop as well.
>
> Thank you for setting this up, Thomas!!!

I just noticed that -rcu and -tip both still have their own version of
"ubsan, kcsan: Don't combine sanitizer with kcov on clang". For there
to not be any conflicts in -next, "ubsan, kcsan: Don't combine
sanitizer with kcov on clang" could be dropped from -rcu.

Thanks,
-- Marco

Re: linux-next: build failure after merge of the tip tree

[Paul E. McKenney]

On Sat, May 23, 2020 at 02:23:45PM -0700, Paul E. McKenney wrote:
> On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> > "Paul E. McKenney"  writes:
> > > On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> > >> core/rcu is the one which diverged and caused the merge conflict with
> > >> PPC to happen twice. So Paul needs to remove the stale core/rcu bits and
> > >> rebase on the current version (which is not going to change again).
> > >
> > > So there will be another noinstr-rcu-* tag, and I will rebase on top
> > > of that, correct?  If so, fair enough!
> > 
> > Here you go: noinstr-rcu-220-05-23
> > 
> > I wanted this to be 2020 and not 220 but I noticed after pushing it
> > out. I guess it still does the job :)
> 
> Now -that- is what I call an old-school tag name!!!  ;-)
> 
> I remerged, rebased, and pushed to -rcu branch "dev".
> 
> If it survives testing, I will reset -rcu branch "rcu/next" as well.

And passed!  The compile times are back to their old selves on my
laptop as well.

Thank you for setting this up, Thomas!!!

Thanx, Paul

Re: linux-next: build failure after merge of the tip tree

[Paul E. McKenney]

On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> "Paul E. McKenney"  writes:
> > On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> >> core/rcu is the one which diverged and caused the merge conflict with
> >> PPC to happen twice. So Paul needs to remove the stale core/rcu bits and
> >> rebase on the current version (which is not going to change again).
> >
> > So there will be another noinstr-rcu-* tag, and I will rebase on top
> > of that, correct?  If so, fair enough!
> 
> Here you go: noinstr-rcu-220-05-23
> 
> I wanted this to be 2020 and not 220 but I noticed after pushing it
> out. I guess it still does the job :)

Now -that- is what I call an old-school tag name!!!  ;-)

I remerged, rebased, and pushed to -rcu branch "dev".

If it survives testing, I will reset -rcu branch "rcu/next" as well.

Thanx, Paul

Re: linux-next: build failure after merge of the tip tree

[Thomas Gleixner]

"Paul E. McKenney"  writes:
> On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
>> core/rcu is the one which diverged and caused the merge conflict with
>> PPC to happen twice. So Paul needs to remove the stale core/rcu bits and
>> rebase on the current version (which is not going to change again).
>
> So there will be another noinstr-rcu-* tag, and I will rebase on top
> of that, correct?  If so, fair enough!

Here you go: noinstr-rcu-220-05-23

I wanted this to be 2020 and not 220 but I noticed after pushing it
out. I guess it still does the job :)

Thanks,

tglx

Re: linux-next: build failure after merge of the tip tree

[Paul E. McKenney]

On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> Borislav Petkov  writes:
> 
> > On Fri, May 22, 2020 at 05:12:23PM -0700, Paul E. McKenney wrote:
> >> Marco, Thomas, is there any better setup I can provide Stephen?  Or
> >> is the next-20200519 -rcu tree the best we have right now?
> >
> > I've queued the fixes yesterday into tip:locking/kcsan and tglx said
> > something about you having to rebase anyway. I guess you can find him on
> > IRC at some point later. :)
> 
> locking/kcsan is not the problem (it just has more fixes on top)
> 
> core/rcu is the one which diverged and caused the merge conflict with
> PPC to happen twice. So Paul needs to remove the stale core/rcu bits and
> rebase on the current version (which is not going to change again).

So there will be another noinstr-rcu-* tag, and I will rebase on top
of that, correct?  If so, fair enough!

Thanx, Paul

Re: linux-next: build failure after merge of the tip tree

[Thomas Gleixner]

Borislav Petkov  writes:

> On Fri, May 22, 2020 at 05:12:23PM -0700, Paul E. McKenney wrote:
>> Marco, Thomas, is there any better setup I can provide Stephen?  Or
>> is the next-20200519 -rcu tree the best we have right now?
>
> I've queued the fixes yesterday into tip:locking/kcsan and tglx said
> something about you having to rebase anyway. I guess you can find him on
> IRC at some point later. :)

locking/kcsan is not the problem (it just has more fixes on top)

core/rcu is the one which diverged and caused the merge conflict with
PPC to happen twice. So Paul needs to remove the stale core/rcu bits and
rebase on the current version (which is not going to change again).

Thanks,

tglx

Re: linux-next: build failure after merge of the tip tree

[Borislav Petkov]

On Fri, May 22, 2020 at 05:12:23PM -0700, Paul E. McKenney wrote:
> Marco, Thomas, is there any better setup I can provide Stephen?  Or
> is the next-20200519 -rcu tree the best we have right now?

I've queued the fixes yesterday into tip:locking/kcsan and tglx said
something about you having to rebase anyway. I guess you can find him on
IRC at some point later. :)

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: linux-next: build failure after merge of the tip tree

[Paul E. McKenney]

On Fri, May 22, 2020 at 05:49:44PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 22 May 2020 17:17:08 +1000 Stephen Rothwell  
> wrote:
> >
> > On Thu, 21 May 2020 18:35:22 +0100 Will Deacon  wrote:
> > >
> > > [+Marco and Boris]
> > > 
> > > On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:  
> > > > After merging the tip tree, all my linux-next builds took signficantly
> > > > longer and used much more memory.  In some cases, builds would seg fault
> > > > due to running out of memory :-(
> > > > 
> > > > I have eventaully bisected it to commit
> > > > 
> > > >   cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN 
> > > > instrumentation")
> > > > 
> > > > For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> > > > -j80) the elapsed time went from around 9 minutes to over 17 minutes
> > > > and the maximum resident size (as reported by /usr/bin/time) from around
> > > > 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> > > > 
> > > > For tomorrow's linux-next (well, later today :-() I will revert that
> > > > commit (and its child) when I merge the tip tree.
> > > 
> > > Sorry about that, seems we can't avoid running into compiler problems with
> > > this lot. The good news is that there's a series to fix this here:
> > > 
> > > https://lore.kernel.org/r/20200521142047.169334-1-el...@google.com
> > > 
> > > so hopefully this be fixed in -tip soon (but I agree that reverting the
> > > thing in -next in the meantime makes sense).  
> > 
> > Unfortunately, the revert didn't work, so instead I have used the tip
> > tree from next-20200518 for today (hopefully this will all be sorted
> > out by Monday).
> 
> And the rcu tree has merged part of the tip tree that contains the
> offending commits, so I have used the version fo the rcu tree from
> next-20200519 for today.

Please accept my apologies for my part of this problem!  I don't see
the slowdowns on my normal test system (possibly due to gcc 4.8.5),
but I do see them on my laptop.

Marco, Thomas, is there any better setup I can provide Stephen?  Or
is the next-20200519 -rcu tree the best we have right now?

Thanx, Paul

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Fri, 22 May 2020 17:17:08 +1000 Stephen Rothwell  
wrote:
>
> On Thu, 21 May 2020 18:35:22 +0100 Will Deacon  wrote:
> >
> > [+Marco and Boris]
> > 
> > On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:  
> > > After merging the tip tree, all my linux-next builds took signficantly
> > > longer and used much more memory.  In some cases, builds would seg fault
> > > due to running out of memory :-(
> > > 
> > > I have eventaully bisected it to commit
> > > 
> > >   cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN 
> > > instrumentation")
> > > 
> > > For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> > > -j80) the elapsed time went from around 9 minutes to over 17 minutes
> > > and the maximum resident size (as reported by /usr/bin/time) from around
> > > 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> > > 
> > > For tomorrow's linux-next (well, later today :-() I will revert that
> > > commit (and its child) when I merge the tip tree.
> > 
> > Sorry about that, seems we can't avoid running into compiler problems with
> > this lot. The good news is that there's a series to fix this here:
> > 
> > https://lore.kernel.org/r/20200521142047.169334-1-el...@google.com
> > 
> > so hopefully this be fixed in -tip soon (but I agree that reverting the
> > thing in -next in the meantime makes sense).  
> 
> Unfortunately, the revert didn't work, so instead I have used the tip
> tree from next-20200518 for today (hopefully this will all be sorted
> out by Monday).

And the rcu tree has merged part of the tip tree that contains the
offending commits, so I have used the version fo the rcu tree from
next-20200519 for today.
-- 
Cheers,
Stephen Rothwell


pgp6_yMrUREFM.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Will,

On Thu, 21 May 2020 18:35:22 +0100 Will Deacon  wrote:
>
> [+Marco and Boris]
> 
> On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:
> > After merging the tip tree, all my linux-next builds took signficantly
> > longer and used much more memory.  In some cases, builds would seg fault
> > due to running out of memory :-(
> > 
> > I have eventaully bisected it to commit
> > 
> >   cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN instrumentation")
> > 
> > For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> > -j80) the elapsed time went from around 9 minutes to over 17 minutes
> > and the maximum resident size (as reported by /usr/bin/time) from around
> > 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> > 
> > For tomorrow's linux-next (well, later today :-() I will revert that
> > commit (and its child) when I merge the tip tree.  
> 
> Sorry about that, seems we can't avoid running into compiler problems with
> this lot. The good news is that there's a series to fix this here:
> 
> https://lore.kernel.org/r/20200521142047.169334-1-el...@google.com
> 
> so hopefully this be fixed in -tip soon (but I agree that reverting the
> thing in -next in the meantime makes sense).

Unfortunately, the revert didn't work, so instead I have used the tip
tree from next-20200518 for today (hopefully this will all be sorted
out by Monday).

-- 
Cheers,
Stephen Rothwell


pgp4323gRKFRp.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Will Deacon]

Hi Stephen,

[+Marco and Boris]

On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:
> After merging the tip tree, all my linux-next builds took signficantly
> longer and used much more memory.  In some cases, builds would seg fault
> due to running out of memory :-(
> 
> I have eventaully bisected it to commit
> 
>   cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN instrumentation")
> 
> For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> -j80) the elapsed time went from around 9 minutes to over 17 minutes
> and the maximum resident size (as reported by /usr/bin/time) from around
> 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> 
> For tomorrow's linux-next (well, later today :-() I will revert that
> commit (and its child) when I merge the tip tree.

Sorry about that, seems we can't avoid running into compiler problems with
this lot. The good news is that there's a series to fix this here:

https://lore.kernel.org/r/20200521142047.169334-1-el...@google.com

so hopefully this be fixed in -tip soon (but I agree that reverting the
thing in -next in the meantime makes sense).

Will

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

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

Thanks.
-- 
Cheers,
Stephen Rothwell


pgp3bI3wEmsAy.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  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

Re: linux-next: build failure after merge of the tip tree

[Daniel Vetter]

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  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

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

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 
> > > 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 
> > > ---
> > >  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.

Re: linux-next: build failure after merge of the tip tree

[Thomas Gleixner]

On Thu, 29 Aug 2019, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> > From: Stephen Rothwell 
> > 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 
> > ---
> >  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

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell 
> 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 
> ---
>  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?

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ilya,

On Wed, 10 Jul 2019 20:21:33 +0200 Ilya Dryomov  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


pgp3xqEtkmhJC.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Ilya Dryomov]

On Wed, Jul 10, 2019 at 2:01 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell  
> 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(_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 
> > 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 
> > ---
> >  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(_dev->lock_rwsem);
> > + lockdep_assert_held_write(_dev->lock_rwsem);
> >
> >   cancel_delayed_work(_dev->lock_dwork);
> >   if (!completion_done(_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(_dev->lock_rwsem);
> > + lockdep_assert_held_write(_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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell  
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(_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 
> 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 
> ---
>  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(_dev->lock_rwsem);
> + lockdep_assert_held_write(_dev->lock_rwsem);
>  
>   cancel_delayed_work(_dev->lock_dwork);
>   if (!completion_done(_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(_dev->lock_rwsem);
> + lockdep_assert_held_write(_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


pgpgstHpXk1iN.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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


pgptZuNOQUmRV.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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


pgp9cePwRmRaS.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi David,

On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba  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(_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


pgpkdOAk8hYmw.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi David,

On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba  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


pgpWXG5dbtty0.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[David Sterba]

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(_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.

Re: linux-next: build failure after merge of the tip tree

[Kalle Valo]

Thomas Gleixner  writes:

> On Tue, 25 Jun 2019, Stephen Rothwell wrote:
>
>> Hi Kalle,
>> 
>> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo  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

Re: linux-next: build failure after merge of the tip tree

[Thomas Gleixner]

On Tue, 25 Jun 2019, Stephen Rothwell wrote:

> Hi Kalle,
> 
> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo  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

Re: linux-next: build failure after merge of the tip tree

[Kalle Valo]

Stephen Rothwell  writes:

> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Kalle,

On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo  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


pgparBFJiBu2s.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the tip tree

[Thomas Gleixner]

On Tue, 25 Jun 2019, Kalle Valo wrote:
> Stephen Rothwell  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

Re: linux-next: build failure after merge of the tip tree

[Kalle Valo]

Stephen Rothwell  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 
> 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 
> ---
>  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

Re: linux-next: build failure after merge of the tip tree

[Joerg Roedel]

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

Re: linux-next: build failure after merge of the tip tree

[Joerg Roedel]

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

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 01:39:08PM +0100, David Howells wrote:
> Peter Zijlstra  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..

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 01:39:08PM +0100, David Howells wrote:
> Peter Zijlstra  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..

Re: linux-next: build failure after merge of the tip tree

[David Howells]

Stephen Rothwell  wrote:

> + wait_var_event(>nr_calls, !atomic_read(>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

Re: linux-next: build failure after merge of the tip tree

[David Howells]

Stephen Rothwell  wrote:

> + wait_var_event(>nr_calls, !atomic_read(>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

Re: linux-next: build failure after merge of the tip tree

[David Howells]

Peter Zijlstra  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

Re: linux-next: build failure after merge of the tip tree

[David Howells]

Peter Zijlstra  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

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

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 :/

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

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 :/

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi Ingo,
> 
> On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi Ingo,
> 
> On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  wrote:
>
> * Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  wrote:
>
> * Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Josh Poimboeuf]

On Wed, Nov 08, 2017 at 10:18:28AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Josh Poimboeuf]

On Wed, Nov 08, 2017 at 10:18:28AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar  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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Josh Poimboeuf  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Josh,

On Tue, 7 Nov 2017 21:01:52 -0600 Josh Poimboeuf  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 

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi Josh,

On Tue, 7 Nov 2017 21:01:52 -0600 Josh Poimboeuf  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 

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the tip tree

[Josh Poimboeuf]

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)

Re: linux-next: build failure after merge of the tip tree

[Josh Poimboeuf]

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)

Re: linux-next: build failure after merge of the tip tree

[Kees Cook]

On Wed, Nov 1, 2017 at 3:51 AM, Stephen Rothwell  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(>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(>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(>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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Kees Cook
Pixel Security

Re: linux-next: build failure after merge of the tip tree

[Kees Cook]

On Wed, Nov 1, 2017 at 3:51 AM, Stephen Rothwell  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(>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(>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(>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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Kees Cook
Pixel Security

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

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  
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 
> 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 
> ---
>  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

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  
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 
> 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 
> ---
>  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi jeffy,

On Wed, 28 Jun 2017 12:00:19 +0800 jeffy  wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar 
> 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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi jeffy,

On Wed, 28 Jun 2017 12:00:19 +0800 jeffy  wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar 
> 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

Re: linux-next: build failure after merge of the tip tree

[jeffy]

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 
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 
---
  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 
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)
  {

Re: linux-next: build failure after merge of the tip tree

[jeffy]

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 
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 
---
  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 
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)
  {

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  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(>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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell  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(>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

Re: linux-next: build failure after merge of the tip tree

[Mikko Perttunen]

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.

Re: linux-next: build failure after merge of the tip tree

[Mikko Perttunen]

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.

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 7 Dec 2016 19:56:32 +0100 Ingo Molnar  wrote:
>
> * Arnaldo Carvalho de Melo  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

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 7 Dec 2016 19:56:32 +0100 Ingo Molnar  wrote:
>
> * Arnaldo Carvalho de Melo  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

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Arnaldo Carvalho de Melo  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  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