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

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

[Stephen Rothwell]

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;
}
 
-- 
2.30.0

-- 
Cheers,
Stephen Rothwell


pgp0wYvH9oZQz.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpoZ3HRf6zCW.pgp
Description: OpenPGP digital signature

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.

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgphrQPytO2Ft.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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'?
  545 |   __max_die_per_package = nodes_per_socket = ((ecx >> 8) & 7) + 1;
  |   ^
  |   topology_max_die_per_package

Caused by commit

  76e2fc63ca40 ("x86/cpu/amd: Set __max_die_per_package on AMD")

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell


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

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

[Stephen Rothwell]

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*()")

[interacting with commit

  35feb60474bf ("kernel/smp: Provide CSD lock timeout diagnostics")

from before v5.10-rc1]

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Fri, 27 Nov 2020 15:04:00 +1100
Subject: [PATCH] smp: fix up "smp: Cleanup smp_call_function*()"

An instance if "dst" was missed.

Fixes: 545b8c8df41f ("smp: Cleanup smp_call_function*()")
Signed-off-by: Stephen Rothwell 
---
 kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index faf1a3ace6a9..1b6070bf97bb 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -130,7 +130,7 @@ static __always_inline int 
csd_lock_wait_getcpu(call_single_data_t *csd)
 
csd_type = CSD_TYPE(csd);
if (csd_type == CSD_TYPE_ASYNC || csd_type == CSD_TYPE_SYNC)
-   return csd->dst; /* Other CSD_TYPE_ values might not have 
->dst. */
+   return csd->node.dst; /* Other CSD_TYPE_ values might not have 
->dst. */
return -1;
 }
 
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell


pgpP4hilBFDk5.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

In file included from include/linux/thread_info.h:38,
 from arch/x86/include/asm/preempt.h:7,
 from include/linux/preempt.h:78,
 from include/linux/spinlock.h:51,
 from include/linux/mmzone.h:8,
 from include/linux/gfp.h:6,
 from include/linux/slab.h:15,
 from include/linux/crypto.h:20,
 from arch/x86/kernel/asm-offsets.c:9:
arch/x86/include/asm/thread_info.h:96: warning: "TIF_NOTIFY_SIGNAL" redefined
   96 | #define TIF_NOTIFY_SIGNAL 19 /* signal notifications exist */
  | 
arch/x86/include/asm/thread_info.h:94: note: this is the location of the 
previous definition
   94 | #define TIF_NOTIFY_SIGNAL 17 /* signal notifications exist */
  | 

Caused by commit

  c8d5ed67936f ("x86: Wire up TIF_NOTIFY_SIGNAL")

interacting with commit

  323b0fba756d ("x86: wire up TIF_NOTIFY_SIGNAL")

from the block tree.

I added the following merge fix patch.

Please sort out these separate versions of the series ... maybe use a
common branch.

From: Stephen Rothwell 
Date: Mon, 9 Nov 2020 14:31:50 +1100
Subject: [PATCH] fix up conflict in "x86: wire up TIF_NOTIFY_SIGNAL" versions

Signed-off-by: Stephen Rothwell 
---
 arch/x86/include/asm/thread_info.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index ec0fcbe739ec..414895e923f5 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -93,7 +93,6 @@ struct thread_info {
 #define TIF_NOTSC  16  /* TSC is not accessible in userland */
 #define TIF_NOTIFY_SIGNAL  17  /* signal notifications exist */
 #define TIF_SLD18  /* Restore split lock detection 
on context switch */
-#define TIF_NOTIFY_SIGNAL  19  /* signal notifications exist */
 #define TIF_MEMDIE 20  /* is terminating due to OOM killer */
 #define TIF_POLLING_NRFLAG 21  /* idle is polling for TIF_NEED_RESCHED 
*/
 #define TIF_IO_BITMAP  22  /* uses I/O bitmap */
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell


pgp8LXFnjzbgR.pgp
Description: OpenPGP digital signature

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

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

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

[Stephen Rothwell]

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__)
  |  ^
tools/include/linux/compiler.h:16:15: note: in definition of macro 
'__compiletime_assert'
   16 |   extern void prefix ## suffix(void) __compiletime_error(msg); \
  |   ^~
tools/include/linux/compiler.h:37:2: note: in expansion of macro 
'_compiletime_assert'
   37 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^~~
tools/include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
  | ^~
tools/include/linux/build_bug.h:59:21: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
   59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
  | ^~~~
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:27:3: note: in expansion of 
macro 'BUILD_BUG'
   27 |   BUILD_BUG(); break; \
  |   ^
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:40:41: note: in expansion of 
macro 'leXX_to_cpu'
   40 |  ({ t r = *(t*)((insn)->next_byte + n); leXX_to_cpu(t, r); })
  | ^~~
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:46:61: note: in expansion of 
macro '__peek_nbyte_next'
   46 |  ({ if (unlikely(!validate_next(t, insn, n))) goto err_out; 
__peek_nbyte_next(t, insn, n); })
  | 
^
util/intel-pt-decoder/../../../arch/x86/lib/insn.c:86:7: note: in expansion of 
macro 'peek_nbyte_next'
   86 |   if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
  |   ^~~

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.

-- 
Cheers,
Stephen Rothwell


pgpW4NysEpBgh.pgp
Description: OpenPGP digital signature

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)
 
 

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

[Stephen Rothwell]

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 have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpkXcEz0PPET.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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

Signed-off-by: Stephen Rothwell 
---
 include/linux/compiler.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d60365d4fb56..b78233fb1af7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -223,12 +223,6 @@ static inline void *offset_to_ptr(const int *off)
 /* [0] degrades to a pointer: a different type from an array */
 #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
 
-/*
- * This is needed in functions which generate the stack canary, see
- * arch/x86/kernel/smpboot.c::start_secondary() for an example.
- */
-#define prevent_tail_call_optimization()   mb()
-
 #include 
 
 /*
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell


pgpwK2MOdmwOX.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

ERROR: modpost: "sched_setscheduler" [drivers/gpu/drm/drm.ko] undefined!

Caused by commit

  616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")

interacting with commit

  5e6c2b4f9161 ("drm/vblank: Add vblank works")

from the drm tree.

I have reverted commit 616d91b68cd5 again for now.

-- 
Cheers,
Stephen Rothwell


pgpCY6Df1WSuW.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpFgX2YyPuf7.pgp
Description: OpenPGP digital signature

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
> 

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

[Stephen Rothwell]

Hi all,

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.

-- 
Cheers,
Stephen Rothwell


pgpEHwTABV1R2.pgp
Description: OpenPGP digital signature

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 

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpdO3dgVVF1M.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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.

-- 
Cheers,
Stephen Rothwell


pgpEQD2fX297t.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

arch/x86/kernel/ftrace.c: In function 'set_ftrace_ops_ro':
arch/x86/kernel/ftrace.c:444:32: error: 'ftrace_epilogue' undeclared (first use 
in this function)
  444 |end_offset = (unsigned long)ftrace_epilogue;
  |^~~

Caused by commit

  0298739b7983 ("x86,ftrace: Fix ftrace_regs_caller() unwind")

from the tip tree ineracting with commit

  59566b0b622e ("x86/ftrace: Have ftrace trampolines turn read-only at the end 
of system boot up")

from Linus' tree.

I applied the following merge fix patch (I don't know if this is
correct, but it seemed reasonable):

From: Stephen Rothwell 
Date: Fri, 15 May 2020 15:51:17 +1000
Subject: [PATCH] fixup for "x86/ftrace: Have ftrace trampolines turn read-only
 at the end of system boot up"

Signed-off-by: Stephen Rothwell 
---
 arch/x86/kernel/ftrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index f8917a6f25b7..c84d28e90a58 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -441,7 +441,7 @@ void set_ftrace_ops_ro(void)
end_offset = (unsigned long)ftrace_regs_caller_end;
} else {
start_offset = (unsigned long)ftrace_caller;
-   end_offset = (unsigned long)ftrace_epilogue;
+   end_offset = (unsigned long)ftrace_caller_end;
}
size = end_offset - start_offset;
size = size + RET_SIZE + sizeof(void *);
-- 
2.26.2

-- 
Cheers,
Stephen Rothwell


pgpk63h7Lms6U.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

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

I added a commit to reenable execute permissions.

-- 
Cheers,
Stephen Rothwell


pgpWVqXqCX6mf.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the drm tree.

I added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Thu, 10 Oct 2019 13:08:43 +1100
Subject: [PATCH] drm/i915: update for mutex_release API change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
 drivers/gpu/drm/i915/i915_active.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

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

-- 
Cheers,
Stephen Rothwell


pgpt8jE0Zti51.pgp
Description: OpenPGP digital signature

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?

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from the sound-asoc tree.

I have added the following merge fix patch:

From: Stephen Rothwell 
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);
 
 static inline bool soc_intel_is_byt_cr(struct platform_device *pdev)
 {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


pgpQRpES1byVY.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

I have reverted that commit for today.

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


pgpLjQCuDkmBv.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

I have added the following patch for today:

From: Stephen Rothwell 
Date: Thu, 1 Aug 2019 13:33:44 +1000
Subject: [PATCH] hrtimer: fix typo in hrtimer_init_sleeper_on_stack() conversion

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/android/vsoc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

-- 
Cheers,
Stephen Rothwell


pgpzOJQWOYR6c.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

drivers/block/rbd.c: In function 'wake_lock_waiters':
drivers/block/rbd.c:3933:2: error: implicit declaration of function 
'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? 
[-Werror=implicit-function-declaration]
  lockdep_assert_held_exclusive(_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;
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


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

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

[Stephen Rothwell]

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

from the btrfs-kdave tree.

I have applied the following merge fix patch:

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

Signed-off-by: Stephen Rothwell 
---
 fs/btrfs/ctree.c  | 2 +-
 fs/btrfs/extent_map.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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

-- 
Cheers,
Stephen Rothwell


pgpSGc3cKK9M6.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

from the wireless-drivers-next tree interacting with commit

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

from the tip tree.

I have added the following merge fix patch:

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

-- 
Cheers,
Stephen Rothwell


pgpd8Vu3HUydV.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

I build with O=

I have appplied the following fix patch for today:

From: Stephen Rothwell 
Date: Tue, 6 Nov 2018 11:37:10 +1100
Subject: [PATCH] fix for "locking/atomics: Check generated headers are
 up-to-date"

Signed-off-by: Stephen Rothwell 
---
 Kbuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

-- 
Cheers,
Stephen Rothwell


pgpVZ_dcCE7Sj.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

I build with O=

I have appplied the following fix patch for today:

From: Stephen Rothwell 
Date: Tue, 6 Nov 2018 11:37:10 +1100
Subject: [PATCH] fix for "locking/atomics: Check generated headers are
 up-to-date"

Signed-off-by: Stephen Rothwell 
---
 Kbuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

-- 
Cheers,
Stephen Rothwell


pgpVZ_dcCE7Sj.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

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

Invalid absolute R_386_32 relocation: __end_rodata_aligned

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

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

-- 
Cheers,
Stephen Rothwell


pgpy6FZFdXACa.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

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

Invalid absolute R_386_32 relocation: __end_rodata_aligned

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

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

-- 
Cheers,
Stephen Rothwell


pgpy6FZFdXACa.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the net-next tree.

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

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

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

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 15:34:48 +1000
Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal

Signed-off-by: Stephen Rothwell 
---
 net/rxrpc/call_accept.c | 2 +-
 net/rxrpc/call_object.c | 4 ++--
 net/rxrpc/conn_object.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

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

-- 
Cheers,
Stephen Rothwell


pgpevV6eCQKBa.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the net-next tree.

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

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

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

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 15:34:48 +1000
Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal

Signed-off-by: Stephen Rothwell 
---
 net/rxrpc/call_accept.c | 2 +-
 net/rxrpc/call_object.c | 4 ++--
 net/rxrpc/conn_object.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

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

-- 
Cheers,
Stephen Rothwell


pgpevV6eCQKBa.pgp
Description: OpenPGP digital signature