[-- Attachment #1: Type: text/plain, Size: 797 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: ERROR: ".perf_arch_fetch_caller_regs" [fs/xfs/xfs.ko] undefined! ERROR: ".perf_arch_fetch_caller_regs" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined! Caused by commit 5331d7b84613b8325362dde53dc2bff2fb87d351 ("perf: Introduce new perf_fetch_caller_regs() for hot regs snapshot") from the tip tree. Presumably commit 639fe4b12f92b54c9c3b38c82cdafaa38cfd3e63 ("perf: export perf_trace_regs and perf_arch_fetch_caller_regs") should have exported the weak version as well as the x86 one. I have used the version of the tip tree from next-20100311 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 678 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory drivers/misc/vmware_balloon.c: In function 'vmballoon_init': drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform' Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up the hypervisor layer"). (Yes, I know this has already been reported.) I have used the version of the tip tree from next-20100507 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
On 05/09/2010 09:49 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory
> drivers/misc/vmware_balloon.c: In function 'vmballoon_init':
> drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform'
>
> Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up
> the hypervisor layer"). (Yes, I know this has already been reported.)
>
> I have used the version of the tip tree from next-20100507 for today.
Working on it.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
[-- Attachment #1: Type: text/plain, Size: 701 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: kernel/debug/kdb/kdb_main.c: In function 'kdb_summary': kernel/debug/kdb/kdb_main.c:2457: error: 'xtime' undeclared (first use in this function) Caused by commit 0fb86b06298b6cd3205cac2e68a499f269282dac ("imekeeping: Make xtime and wall_to_monotonic static") from the tip tree interacting with commit 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb back end (1 of 2)") which was merged before v2.6.35-rc1. I have used the tip tree from next-20100727 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #1: Type: text/plain, Size: 523 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: /bin/sh: /scratch/sfr/x86_64_allmodconfig/scripts/recordmcount: No such file or directory I use O=/scratch/sfr/x86_64_allmodconfig in this build. The same happened yesterday, but it fixed itself when I rebuilt for other reasons. Andrew has also reported this so I applied the patch you suggested. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #1: Type: text/plain, Size: 608 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem: Convert memmove() to assembly file and fix return value bug") interacting with our build system. After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build before merging the tip tree) from my object tree, it built correctly. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #1: Type: text/plain, Size: 966 bytes --] Hi all, On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory > > Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem: > Convert memmove() to assembly file and fix return value bug") interacting > with our build system. > > After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build > before merging the tip tree) from my object tree, it built correctly. I am still getting this (of course). Michal, is there anything that the kbuild system can do for us here? Basically we have changed from using a .c file to generate a .o to using a .S but the build system does not regenerate the .cmd file. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
On 17.2.2011 04:47, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
>>
>> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
>> Convert memmove() to assembly file and fix return value bug") interacting
>> with our build system.
>>
>> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
>> before merging the tip tree) from my object tree, it built correctly.
>
> I am still getting this (of course).
>
> Michal, is there anything that the kbuild system can do for us here?
> Basically we have changed from using a .c file to generate a .o to using
> a .S but the build system does not regenerate the .cmd file.
_Maybe_ we could work around it by letting fixdep remove the actual
source file from the list of dependencies in the .cmd file. The
dependency on the .c / .S / whatever file is given by the Makefiles, the
.cmd file is only needed for additional dependencies on headers. Let's
see what else breaks then ;).
Michal
On Thu, Feb 17, 2011 at 02:18:18PM +0100, Michal Marek wrote: > On 17.2.2011 04:47, Stephen Rothwell wrote: > > Hi all, > > > > On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> > >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > >> failed like this: > >> > >> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory > >> > >> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem: > >> Convert memmove() to assembly file and fix return value bug") interacting > >> with our build system. > >> > >> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build > >> before merging the tip tree) from my object tree, it built correctly. > > > > I am still getting this (of course). > > > > Michal, is there anything that the kbuild system can do for us here? > > Basically we have changed from using a .c file to generate a .o to using > > a .S but the build system does not regenerate the .cmd file. > > _Maybe_ we could work around it by letting fixdep remove the actual > source file from the list of dependencies in the .cmd file. The > dependency on the .c / .S / whatever file is given by the Makefiles, the > .cmd file is only needed for additional dependencies on headers. Let's > see what else breaks then ;). It seems to work for me. Can you try the patch below? It needs to be applied before merging 9599ec0 to have any effect. Michal From: Michal Marek <mmarek@suse.cz> Subject: [PATCH] fixdep: Do not record dependency on the source file itself The dependency is already expressed by the Makefiles, storing it in the .cmd file breaks build if a .c file is replaced by .S or vice versa, because the .cmd file contains foo/bar.o: foo/bar.c ... foo/bar.c ... : so the foo/bar.c -> foo/bar.o rule triggers even if there is no foo/bar.c anymore. Signed-off-by: Michal Marek <mmarek@suse.cz> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c index c9a16ab..9264725 100644 --- a/scripts/basic/fixdep.c +++ b/scripts/basic/fixdep.c @@ -315,6 +315,7 @@ static void parse_dep_file(void *map, size_t len) char *end = m + len; char *p; char s[PATH_MAX]; + int first; p = strchr(m, ':'); if (!p) { @@ -327,6 +328,7 @@ static void parse_dep_file(void *map, size_t len) clear_config(); + first = 1; while (m < end) { while (m < end && (*m == ' ' || *m == '\\' || *m == '\n')) m++; @@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len) if (strrcmp(s, "include/generated/autoconf.h") && strrcmp(s, "arch/um/include/uml-config.h") && strrcmp(s, ".ver")) { - printf(" %s \\\n", s); + /* Do not output the first dependency (the + * source file), so that kbuild is not confused + * if a .c file is rewritten into .S or vice + * versa. + */ + if (!first) + printf(" %s \\\n", s); do_config_file(s); } + first = 0; m = p + 1; } printf("\n%s: $(deps_%s)\n\n", target, target);
* Michal Marek <mmarek@suse.cz> wrote:
> @@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
> if (strrcmp(s, "include/generated/autoconf.h") &&
> strrcmp(s, "arch/um/include/uml-config.h") &&
> strrcmp(s, ".ver")) {
> - printf(" %s \\\n", s);
> + /* Do not output the first dependency (the
> + * source file), so that kbuild is not confused
> + * if a .c file is rewritten into .S or vice
> + * versa.
> + */
Just a really minor nitpick, please use the standard comment style:
/*
* Comment .....
* ...... goes here.
*/
specified in Documentation/CodingStyle.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 872 bytes --] Hi Michal, On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote: > > > _Maybe_ we could work around it by letting fixdep remove the actual > > source file from the list of dependencies in the .cmd file. The > > dependency on the .c / .S / whatever file is given by the Makefiles, the > > .cmd file is only needed for additional dependencies on headers. Let's > > see what else breaks then ;). > > It seems to work for me. Can you try the patch below? It needs to be > applied before merging 9599ec0 to have any effect. Thanks, I will apply this as a fix on top of Linus' tree before I merge anything else. It looks simple enough that Linus may take it as a fix right now. Better to convince ourselves first, though, right? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --] Hi Michal, On Fri, 18 Feb 2011 09:47:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote: > > > > > _Maybe_ we could work around it by letting fixdep remove the actual > > > source file from the list of dependencies in the .cmd file. The > > > dependency on the .c / .S / whatever file is given by the Makefiles, the > > > .cmd file is only needed for additional dependencies on headers. Let's > > > see what else breaks then ;). > > > > It seems to work for me. Can you try the patch below? It needs to be > > applied before merging 9599ec0 to have any effect. > > Thanks, I will apply this as a fix on top of Linus' tree before I merge > anything else. It looks simple enough that Linus may take it as a fix > right now. Better to convince ourselves first, though, right? That patch fixed the problem for me and has caused no obvious problems. Acked-by: Stephen Rothwell <sfr@canb.auug.org.au> -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/i2c/busses/i2c-designware-core.c: In function 'i2c_dw_wait_bus_not_busy': drivers/i2c/busses/i2c-designware-core.c:321: error: implicit declaration of function 'mdelay' Caused by commit 800c56383dcb ("i2c-designware: split of i2c-designware.c into core and bus specific parts") from the bjdooks-i2c tree and exposed by commit ca444564a947 ("x86: Stop including <linux/delay.h> in two asm header files"). I have added this patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 1 Apr 2011 12:48:53 +1100 Subject: [PATCH] i2c-designware: mdelay use needs linux/delay.h inclusion Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/i2c/busses/i2c-designware-core.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c index 299e717..f87e25a 100644 --- a/drivers/i2c/busses/i2c-designware-core.c +++ b/drivers/i2c/busses/i2c-designware-core.c @@ -25,6 +25,7 @@ * ---------------------------------------------------------------------------- * */ +#include <linux/delay.h> #include <linux/clk.h> #include <linux/errno.h> #include <linux/err.h> -- 1.7.4.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
[-- Attachment #1: Type: text/plain, Size: 829 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/kernel/i8253.c: In function 'setup_pit_timer': arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init' arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function) Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent"). clockevent_i8253_init() doesn't appear to be declared in any header file even though it is introduced as a global function in commit 9f9119424bbc ("i8253: Create common clockevent implementation"). Similarly for i8253_clockevent. I have used the tip tree from next-20110624 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
I've already reported this to Thomas with a patch attached. See https://lkml.org/lkml/2011/6/25/62 Regards, Stijn On Mon, Jun 27, 2011 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/kernel/i8253.c: In function 'setup_pit_timer': > arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init' > arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function) > > Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent"). > clockevent_i8253_init() doesn't appear to be declared in any header file > even though it is introduced as a global function in commit 9f9119424bbc > ("i8253: Create common clockevent implementation"). Similarly for > i8253_clockevent. > > I have used the tip tree from next-20110624 for today. > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au > http://www.canb.auug.org.au/~sfr/ >
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr': net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration] net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default] net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool': net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Caused by commit 1230db8e1543 ("llist: Make some llist functions inline") interacting with commit 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist") from the net tree. The former commit removes the declarations of llist_del_first() and llist_add_batch() with no explanation (and probably by accident since the definitions still exist). I have added the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 5 Oct 2011 17:16:29 +1100 Subject: [PATCH] llist: add back llist_add_batch and llist_del_first Commit 1230db8e1543 ("llist: Make some llist functions inline") appears to have deleted the definitions by accident. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/llist.h | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/linux/llist.h b/include/linux/llist.h index 837fb4a..7287734 100644 --- a/include/linux/llist.h +++ b/include/linux/llist.h @@ -178,4 +178,10 @@ static inline struct llist_node *llist_del_all(struct llist_head *head) { return xchg(&head->first, NULL); } + +extern bool llist_add_batch(struct llist_node *new_first, + struct llist_node *new_last, + struct llist_head *head); +extern struct llist_node *llist_del_first(struct llist_head *head); + #endif /* LLIST_H */ -- 1.7.6.3 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
>
> Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> net/rds/xlist.h with llist") from the net tree. The former commit
> removes the declarations of llist_del_first() and llist_add_batch() with
> no explanation (and probably by accident since the definitions still
> exist).
Ugh yes, my bad. Ingo objected to inlining all those functions and I
then screwed up. There are no users of those two functions in my tree.
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --] Hi all, On Wed, 05 Oct 2011 10:46:13 +0200 Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote: > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr': > > net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration] > > net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default] > > net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool': > > net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration] > > cc1: some warnings being treated as errors > > > > Caused by commit 1230db8e1543 ("llist: Make some llist functions inline") > > interacting with commit 1bc144b62524 ("net, rds, Replace xlist in > > net/rds/xlist.h with llist") from the net tree. The former commit > > removes the declarations of llist_del_first() and llist_add_batch() with > > no explanation (and probably by accident since the definitions still > > exist). > > Ugh yes, my bad. Ingo objected to inlining all those functions and I > then screwed up. There are no users of those two functions in my tree. So can we have that fixed, please? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1669 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64_allmodconfig) failed like this: /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy:arch/x86/vdso/vdso-note-x32.o: Invalid bfd target I appears that we need a 2.22 binutils :-( $ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --version GNU objcopy (GNU Binutils) 2.21 $ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --help . . /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex I have applied the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 24 Feb 2012 14:27:17 +1100 Subject: [PATCH] x86: mark X86_X32_ABI broken for now until I get a better binutils Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 59c5b9c..e63a4dd 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2159,7 +2159,7 @@ config IA32_AOUT config X86_X32_ABI bool "x32 ABI for 64-bit mode (EXPERIMENTAL)" - depends on X86_64 && IA32_EMULATION && EXPERIMENTAL + depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN ---help--- Include code to run binaries for the x32 native 32-bit ABI for 64-bit processors. An x32 process gets access to the -- 1.7.9.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 539 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/android/binder.c: In function 'task_get_unused_fd_flags': drivers/staging/android/binder.c:383:39: error: request for member 'fds_bits' in something not a structure or union Caused by commit 1fd36adcd98c ("Replace the fd_sets in struct fdtable with an array of unsigned longs"). I have used the tip tree from next-20120223 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown"). Following previous instructions, I have disabled the staging tree driver using this patch (pending a fix in the tip tree): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 8 Mar 2012 15:15:44 +1100 Subject: [PATCH] staging: disable the sep driver due to breakage Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/staging/sep/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/sep/Kconfig b/drivers/staging/sep/Kconfig index 92bf166..cd95ca2 100644 --- a/drivers/staging/sep/Kconfig +++ b/drivers/staging/sep/Kconfig @@ -1,6 +1,6 @@ config DX_SEP tristate "Discretix SEP driver" - depends on PCI + depends on PCI && BROKEN help Discretix SEP driver; used for the security processor subsystem on bard the Intel Mobile Internet Device. -- 1.7.9.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
>
> Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
>
> Following previous instructions, I have disabled the staging tree driver
> using this patch (pending a fix in the tip tree):
Looks good to me. Alan, care to send me an update that fixes this
driver for real?
thanks,
greg k-h
[-- Attachment #1: Type: text/plain, Size: 777 bytes --] Hi all, On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote: > > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote: > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory > > > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown"). > > > > Following previous instructions, I have disabled the staging tree driver > > using this patch (pending a fix in the tip tree): > > Looks good to me. Alan, care to send me an update that fixes this > driver for real? Was this ever fixed? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Wed, Mar 21, 2012 at 09:00:38AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > >
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > >
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> >
> > Looks good to me. Alan, care to send me an update that fixes this
> > driver for real?
>
> Was this ever fixed?
I never got a patch from Alan or anyone else to do this :(
On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > >
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > >
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> >
> > Looks good to me. Alan, care to send me an update that fixes this
> > driver for real?
>
> Was this ever fixed?
I thought it was but apparently it got lost or I dropped the ball. I'll
sort it once git.kernel.org is back and I can pull a currentish -next
tree.
Alan
On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > >
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > >
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> >
> > Looks good to me. Alan, care to send me an update that fixes this
> > driver for real?
>
> Was this ever fixed?
We don't even have a sep_driver.c any more. The massive rework of the SEP
driver dealt with this.
Alan
[-- Attachment #1: Type: text/plain, Size: 294 bytes --] Hi Alan, On Wed, 21 Mar 2012 12:19:54 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > We don't even have a sep_driver.c any more. The massive rework of the SEP > driver dealt with this. Excellent, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 507 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu': drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore' Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread infrastructure"). I have used the tip tree from next-20120814 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu': > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore' > > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread > infrastructure"). > > I have used the tip tree from next-20120814 for today. My first reaction was "we tested that!!!", but I see the conversion from while(1) to do-while. Does the following cure it? Thanx, Paul ------------------------------------------------------------------------ infiniband: ehca: Fix while->do-while conversion typo This commit just adds a needed semicolon. Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c index 4eeac40..83a0095 100644 --- a/drivers/infiniband/hw/ehca/ehca_irq.c +++ b/drivers/infiniband/hw/ehca/ehca_irq.c @@ -668,7 +668,7 @@ static int find_next_online_cpu(struct ehca_comp_pool *pool) if (cpu >= nr_cpu_ids) cpu = cpumask_first(cpu_online_mask); pool->last_cpu = cpu; - } while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active) + } while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active); spin_unlock_irqrestore(&pool->last_cpu_lock, flags); return cpu;
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --] Hi Paul, On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote: > > > > After merging the tip tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu': > > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore' > > > > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread > > infrastructure"). > > > > I have used the tip tree from next-20120814 for today. > > My first reaction was "we tested that!!!", but I see the conversion > from while(1) to do-while. Does the following cure it? Yes, that fixes the build problem. However, the same commit is also responsible for all these new warnings: drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task': drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park': drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task': drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void drivers/infiniband/hw/ehca/ehca_irq.c: At top level: drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type Please address these. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Fri, Aug 17, 2012 at 10:56:33AM +1000, Stephen Rothwell wrote: > Hi Paul, > > On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > > On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote: > > > > > > After merging the tip tree, today's linux-next build (powerpc > > > ppc64_defconfig) failed like this: > > > > > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu': > > > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore' > > > > > > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread > > > infrastructure"). > > > > > > I have used the tip tree from next-20120814 for today. > > > > My first reaction was "we tested that!!!", but I see the conversion > > from while(1) to do-while. Does the following cure it? > > Yes, that fixes the build problem. > > However, the same commit is also responsible for all these new warnings: > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task': > drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type > drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park': > drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task': > drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void > drivers/infiniband/hw/ehca/ehca_irq.c: At top level: > drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type > > Please address these. Does the following help? Thanx, Paul ------------------------------------------------------------------------ infiniband: ehca: Fix compiler warnings Fix comp_task() to return void to match smp_hotplug_thread's thread_fn member, and adjust indirection on the ->cpu_comp_threads per-CPU member of the ehca_comp_pool structure. Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org> diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c index 83a0095..8615d7c 100644 --- a/drivers/infiniband/hw/ehca/ehca_irq.c +++ b/drivers/infiniband/hw/ehca/ehca_irq.c @@ -707,7 +707,7 @@ static void queue_comp_task(struct ehca_cq *__cq) BUG_ON(!cpu_online(cpu_id)); cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id); - thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id); + thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id); BUG_ON(!cct || !thread); spin_lock_irqsave(&cct->task_lock, flags); @@ -716,7 +716,7 @@ static void queue_comp_task(struct ehca_cq *__cq) if (cq_jobs > 0) { cpu_id = find_next_online_cpu(pool); cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id); - thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id); + thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id); BUG_ON(!cct || !thread); } __queue_comp_task(__cq, cct, thread); @@ -761,7 +761,7 @@ static void comp_task_park(unsigned int cpu) cpu = find_next_online_cpu(pool); target = per_cpu_ptr(pool->cpu_comp_tasks, cpu); - thread = per_cpu_ptr(pool->cpu_comp_threads, cpu); + thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu); spin_lock_irq(&target->task_lock); list_for_each_entry_safe(cq, tmp, &list, entry) { list_del(&cq->entry); @@ -788,7 +788,7 @@ static int comp_task_should_run(unsigned int cpu) return cct->cq_jobs; } -static int comp_task(unsigned int cpu) +static void comp_task(unsigned int cpu) { struct ehca_cpu_comp_task *cct = this_cpu_ptr(pool->cpu_comp_tasks); int cql_empty;
[-- Attachment #1: Type: text/plain, Size: 339 bytes --] Hi Paul, On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > Does the following help? Yes, that fixes the warnings. Please submit those two patches to the tip folks ASAP as I can't build the tip tree without them. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Mon, Aug 20, 2012 at 02:54:04PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Does the following help?
>
> Yes, that fixes the warnings. Please submit those two patches to the tip
> folks ASAP as I can't build the tip tree without them.
Will do. Unless you tell me otherwise, with your Tested-by.
Thanx, Paul
[-- Attachment #1: Type: text/plain, Size: 3674 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 'power7_events_attr[0]') [-Werror] arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 'power7_events_attr[1]') [-Werror] arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 'power7_events_attr[2]') [-Werror] arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 'power7_events_attr[3]') [-Werror] arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 'power7_events_attr[4]') [-Werror] arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 'power7_events_attr[5]') [-Werror] arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 'power7_events_attr[6]') [-Werror] arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 'power7_events_attr[7]') [-Werror] arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 'power7_events_attr[8]') [-Werror] arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 'power7_events_attr[9]') [-Werror] arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 'power7_events_attr[10]') [-Werror] arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 'power7_events_attr[11]') [-Werror] arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 'power7_events_attr[12]') [-Werror] arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 'power7_events_attr[13]') [-Werror] arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 'power7_events_attr[14]') [-Werror] arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible pointer type [-Werror] arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 'power7_events_attr[15]') [-Werror] Caused by commit 1c53a270724d ("perf/POWER7: Make generic event translations available in sysfs"). I have used the tip tree from 20130128 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/thermal/intel_powerclamp.c: In function 'clamp_thread': drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function) Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel PowerClamp Driver") from the thermal tree. I applied this merge fix patch and can carry it as necessary: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 14 Feb 2013 13:26:22 +1100 Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/thermal/intel_powerclamp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c index ab3ed90..b40b37c 100644 --- a/drivers/thermal/intel_powerclamp.c +++ b/drivers/thermal/intel_powerclamp.c @@ -50,6 +50,7 @@ #include <linux/tick.h> #include <linux/debugfs.h> #include <linux/seq_file.h> +#include <linux/sched/rt.h> #include <asm/nmi.h> #include <asm/msr.h> -- 1.8.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --] Hi all, On Thu, 14 Feb 2013 13:30:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/thermal/intel_powerclamp.c: In function 'clamp_thread': > drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function) > > Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new > header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel > PowerClamp Driver") from the thermal tree. > > I applied this merge fix patch and can carry it as necessary: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 14 Feb 2013 13:26:22 +1100 > Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/thermal/intel_powerclamp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c > index ab3ed90..b40b37c 100644 > --- a/drivers/thermal/intel_powerclamp.c > +++ b/drivers/thermal/intel_powerclamp.c > @@ -50,6 +50,7 @@ > #include <linux/tick.h> > #include <linux/debugfs.h> > #include <linux/seq_file.h> > +#include <linux/sched/rt.h> > > #include <asm/nmi.h> > #include <asm/msr.h> The above fix is now needed when the thermal tree is merged with Linus' tree ... -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6151 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/firmware/efi/efivars.c: In function 'efivar_release': drivers/firmware/efi/efivars.c:300:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] drivers/firmware/efi/efivars.c: In function 'efivar_create': drivers/firmware/efi/efivars.c:341:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] drivers/firmware/efi/efivars.c:341:12: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efivars.c: In function 'efivar_create_sysfs_entry': drivers/firmware/efi/efivars.c:420:13: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efivars.c: In function 'create_efivars_bin_attributes': drivers/firmware/efi/efivars.c:460:7: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efivars.c:470:7: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efivars.c: In function 'efivar_update_sysfs_entries': drivers/firmware/efi/efivars.c:527:8: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efivars.c: In function 'efivars_sysfs_callback': drivers/firmware/efi/efivars.c:551:8: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/inode.c: In function 'efivarfs_create': fs/efivarfs/inode.c:115:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] fs/efivarfs/inode.c:115:6: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/inode.c:139:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] fs/efivarfs/file.c: In function 'efivarfs_file_write': fs/efivarfs/file.c:35:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] fs/efivarfs/file.c:35:7: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/file.c:62:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] fs/efivarfs/file.c: In function 'efivarfs_file_read': fs/efivarfs/file.c:81:7: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/super.c: In function 'efivarfs_callback': fs/efivarfs/super.c:132:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] fs/efivarfs/super.c:132:8: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/super.c:142:7: warning: assignment makes pointer from integer without a cast [enabled by default] fs/efivarfs/super.c:166:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] drivers/firmware/efi/efi-pstore.c: In function 'efi_pstore_read_func': drivers/firmware/efi/efi-pstore.c:77:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] drivers/firmware/efi/efi-pstore.c:77:16: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/firmware/efi/efi-pstore.c: In function 'efivars_pstore_init': drivers/firmware/efi/efi-pstore.c:225:22: warning: assignment makes pointer from integer without a cast [enabled by default] Probably caused by commits d68772b7c83f ("efivarfs: Move to fs/efivarfs") and/or a9499fa7cd3f ("efi: split efisubsystem from efivars") interacting with some header inclusion changes in the rest of today's trees. See Rule 1 from Documentation/SubmitChecklist. I have applied the following merge fix patch for today (this won't quite apply to the tip tree due to the other patch adding linux/magic.h to fs/efivarfs/super.c, but that could be applied as well): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 29 Apr 2013 15:34:28 +1000 Subject: [PATCH] efivars: use of kmalloc etc requires the inclusion of slab.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/firmware/efi/efivars.c | 1 + fs/efivarfs/file.c | 1 + fs/efivarfs/inode.c | 1 + fs/efivarfs/super.c | 1 + drivers/firmware/efi/efi-pstore.c | 1 + 5 files changed, 5 insertions(+) diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c index f8f5e5d..66928a3 100644 --- a/drivers/firmware/efi/efivars.c +++ b/drivers/firmware/efi/efivars.c @@ -68,6 +68,7 @@ #include <linux/efi.h> #include <linux/module.h> #include <linux/ucs2_string.h> +#include <linux/slab.h> #define EFIVARS_VERSION "0.08" #define EFIVARS_DATE "2004-May-17" diff --git a/fs/efivarfs/file.c b/fs/efivarfs/file.c index ede07fc..bfb5315 100644 --- a/fs/efivarfs/file.c +++ b/fs/efivarfs/file.c @@ -9,6 +9,7 @@ #include <linux/efi.h> #include <linux/fs.h> +#include <linux/slab.h> #include "internal.h" diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c index 640e289..7e787fb 100644 --- a/fs/efivarfs/inode.c +++ b/fs/efivarfs/inode.c @@ -10,6 +10,7 @@ #include <linux/efi.h> #include <linux/fs.h> #include <linux/ctype.h> +#include <linux/slab.h> #include "internal.h" diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 1fa5e6d..94d9192 100644 --- a/fs/efivarfs/super.c +++ b/fs/efivarfs/super.c @@ -12,6 +12,7 @@ #include <linux/fs.h> #include <linux/module.h> #include <linux/pagemap.h> +#include <linux/slab.h> #include <linux/magic.h> #include "internal.h" diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c index 221ad1b..0242795 100644 --- a/drivers/firmware/efi/efi-pstore.c +++ b/drivers/firmware/efi/efi-pstore.c @@ -2,6 +2,7 @@ #include <linux/module.h> #include <linux/pstore.h> #include <linux/ucs2_string.h> +#include <linux/slab.h> #define DUMP_NAME_LEN 52 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1931 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0, from /scratch/sfr/next/include/linux/gfp.h:4, from /scratch/sfr/next/include/linux/kmod.h:22, from /scratch/sfr/next/include/linux/module.h:13, from /scratch/sfr/next/block/blk-mq.c:2: /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter': /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret' __ret; \ ^ /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq' ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, ^ /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, ^ Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*() interface more friendly"). Since this was also in next-20131025, I applied the following merge fix commit for today, please fix this in the tip tree. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 28 Oct 2013 20:19:27 +1100 Subject: [PATCH] sched/wait: fix missing semicolon Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/wait.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/wait.h b/include/linux/wait.h index 7f8caa519128..fcc968087f05 100644 --- a/include/linux/wait.h +++ b/include/linux/wait.h @@ -768,7 +768,7 @@ do { \ int __ret = 0; \ if (!(condition)) \ __ret = __wait_event_interruptible_lock_irq(wq, \ - condition, lock,) \ + condition, lock,); \ __ret; \ }) -- 1.8.4.rc3 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --] On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0, > from /scratch/sfr/next/include/linux/gfp.h:4, > from /scratch/sfr/next/include/linux/kmod.h:22, > from /scratch/sfr/next/include/linux/module.h:13, > from /scratch/sfr/next/block/blk-mq.c:2: > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter': > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret' > __ret; \ > ^ > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq' > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, > ^ > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, > ^ > > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*() > interface more friendly"). > > Since this was also in next-20131025, I applied the following merge fix > commit for today, please fix this in the tip tree. FWIW I got confirmation on Oct 23 that this had been committed to the tip tree. So I guess it just wasn't pushed yet. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
* Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
> > from /scratch/sfr/next/include/linux/gfp.h:4,
> > from /scratch/sfr/next/include/linux/kmod.h:22,
> > from /scratch/sfr/next/include/linux/module.h:13,
> > from /scratch/sfr/next/block/blk-mq.c:2:
> > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
> > __ret; \
> > ^
> > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
> > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > ^
> > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
> > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > ^
> >
> > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> > interface more friendly").
> >
> > Since this was also in next-20131025, I applied the following merge fix
> > commit for today, please fix this in the tip tree.
>
> FWIW I got confirmation on Oct 23 that this had been committed to the
> tip tree. So I guess it just wasn't pushed yet.
I merged the fix intoo the linux-next branch earlier today so it
should be resolved soon.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --] Hi Ingo, On Mon, 28 Oct 2013 11:26:04 +0100 Ingo Molnar <mingo@kernel.org> wrote: > > * Thierry Reding <thierry.reding@gmail.com> wrote: > > > On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote: > > > > > > After merging the tip tree, today's linux-next build (powerpc > > > ppc64_defconfig) failed like this: > > > > > > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0, > > > from /scratch/sfr/next/include/linux/gfp.h:4, > > > from /scratch/sfr/next/include/linux/kmod.h:22, > > > from /scratch/sfr/next/include/linux/module.h:13, > > > from /scratch/sfr/next/block/blk-mq.c:2: > > > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter': > > > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret' > > > __ret; \ > > > ^ > > > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq' > > > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, > > > ^ > > > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be > > > ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq, > > > ^ > > > > > > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*() > > > interface more friendly"). > > > > > > Since this was also in next-20131025, I applied the following merge fix > > > commit for today, please fix this in the tip tree. > > > > FWIW I got confirmation on Oct 23 that this had been committed to the > > tip tree. So I guess it just wasn't pushed yet. > > I merged the fix intoo the linux-next branch earlier today so it > should be resolved soon. Excellent, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 709 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs': drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration] preempt_check_resched(); ^ Caused by commit 62b94a08da1b ("sched/preempt: Take away preempt_enable_no_resched() from modules") interacting with commit 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the pm tree. For now, I have reverted that pm tree commit. Please sort this out. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
> preempt_check_resched();
> ^
>
> Caused by commit 62b94a08da1b ("sched/preempt: Take away
> preempt_enable_no_resched() from modules") interacting with commit
> 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> pm tree.
I think that pm commit is a very good example of why the sched/preempt
patch is a very good idea.
Also that Changelog fails to explain why enabling interrupts helps. What
interrupt is required for progress, and how does it make the progress
happen.
On Tue, 14 Jan 2014, Peter Zijlstra wrote: > On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs': > > drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration] > > preempt_check_resched(); > > ^ > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away > > preempt_enable_no_resched() from modules") interacting with commit > > 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the > > pm tree. Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help? > I think that pm commit is a very good example of why the sched/preempt > patch is a very good idea. > > Also that Changelog fails to explain why enabling interrupts helps. What > interrupt is required for progress, and how does it make the progress > happen. There is no explanation. It's hardware issue and I have no documentation for the hardware. The general problem is that if there are bus-master transfers running (or possibly for other hardware reasons), the CPU refuses to change frequency. You can wait a little bit and retry and maybe you succeed changing the frequency next time. If you enable interrupts, wait, disable interrupts and retry, you may succeed. If you keep interrupts disabled and retry, you never succeed, no matter how long do you wait. I found it experimentally, I don't know reason for that. Mikulas
On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote: > On Tue, 14 Jan 2014, Peter Zijlstra wrote: > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away > > > preempt_enable_no_resched() from modules") Read these two lines, then note that: > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help? this obviously will not work as preempt_check_resched() and preempt_enable_no_resched() are no longer available to modules. > > I think that pm commit is a very good example of why the sched/preempt > > patch is a very good idea. > > > > Also that Changelog fails to explain why enabling interrupts helps. What > > interrupt is required for progress, and how does it make the progress > > happen. > > There is no explanation. It's hardware issue and I have no documentation > for the hardware. Rafael works for Intel, he ought to be able to figure out wtf the hardware does/needs. > The general problem is that if there are bus-master transfers running (or > possibly for other hardware reasons), the CPU refuses to change frequency. > You can wait a little bit and retry and maybe you succeed changing the > frequency next time. > > If you enable interrupts, wait, disable interrupts and retry, you may > succeed. If you keep interrupts disabled and retry, you never succeed, no > matter how long do you wait. I found it experimentally, I don't know > reason for that. Sounds like magic goo.. In any case, try the below, it does the same but is far less horrid. --- drivers/cpufreq/speedstep-smi.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c index 0f5326d6f79f..57d31538c248 100644 --- a/drivers/cpufreq/speedstep-smi.c +++ b/drivers/cpufreq/speedstep-smi.c @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state) return; /* Disable IRQs */ + preempt_disable(); local_irq_save(flags); command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff); @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state) if (retry) { pr_debug("retry %u, previous result %u, waiting...\n", retry, result); + local_irq_restore(flags); mdelay(retry * 50); + local_irq_save(flags); } retry++; __asm__ __volatile__( @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state) /* enable IRQs */ local_irq_restore(flags); + preempt_enable(); if (new_state == state) pr_debug("change to %u MHz succeeded after %u tries "
On Tue, 14 Jan 2014, Peter Zijlstra wrote: > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote: > > On Tue, 14 Jan 2014, Peter Zijlstra wrote: > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away > > > > preempt_enable_no_resched() from modules") > > Read these two lines, then note that: > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help? > > this obviously will not work as preempt_check_resched() and > preempt_enable_no_resched() are no longer available to modules. I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to linux-next, that broke my patch. > > > I think that pm commit is a very good example of why the sched/preempt > > > patch is a very good idea. > > > > > > Also that Changelog fails to explain why enabling interrupts helps. What > > > interrupt is required for progress, and how does it make the progress > > > happen. > > > > There is no explanation. It's hardware issue and I have no documentation > > for the hardware. > > Rafael works for Intel, he ought to be able to figure out wtf the > hardware does/needs. > > > The general problem is that if there are bus-master transfers running (or > > possibly for other hardware reasons), the CPU refuses to change frequency. > > You can wait a little bit and retry and maybe you succeed changing the > > frequency next time. > > > > If you enable interrupts, wait, disable interrupts and retry, you may > > succeed. If you keep interrupts disabled and retry, you never succeed, no > > matter how long do you wait. I found it experimentally, I don't know > > reason for that. > > Sounds like magic goo.. > > In any case, try the below, it does the same but is far less horrid. > > --- > drivers/cpufreq/speedstep-smi.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c > index 0f5326d6f79f..57d31538c248 100644 > --- a/drivers/cpufreq/speedstep-smi.c > +++ b/drivers/cpufreq/speedstep-smi.c > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state) > return; > > /* Disable IRQs */ > + preempt_disable(); > local_irq_save(flags); > > command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff); > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state) > if (retry) { > pr_debug("retry %u, previous result %u, waiting...\n", > retry, result); > + local_irq_restore(flags); ^^^ this is wrong, because the function speedstep_set_state may already be called with interrupts disabled from speedstep_get_freqs. So, you need to enable interrupts unconditionally, even if they were disabled at the beginning of the function speedstep_set_state. I know it's dirty to enable interrupts in a function that was called with disabled interrupts, but here it must be so (you could rewrite speedstep_get_freqs to not disable interrupts if you want to avoid this dirtiness). > mdelay(retry * 50); > + local_irq_save(flags); > } > retry++; > __asm__ __volatile__( > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state) > > /* enable IRQs */ > local_irq_restore(flags); > + preempt_enable(); > > if (new_state == state) > pr_debug("change to %u MHz succeeded after %u tries " You need also preempt_disable/enable in speedstep_get_freqs. Here I'm resending the patch, to account for 62b94a08da1bae9d187d49dfcd6665af393750f8. From: Mikulas Patocka <mpatocka@redhat.com> speedstep-smi: enable interrupts when waiting On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the speedstep-smi driver sometimes loads and sometimes doesn't load with "change to state X failed" message. I found out that we need to enable interrupts while waiting. When we enable interrupts, the blockage that prevents frequency transition resolves and the transition is possible. With disabled interrupts, the blockage doesn't resolve (no matter how long do we wait). This patch enables interrupts in the function speedstep_set_state that can be called with disabled interrupts. However, this function is called with disabled interrupts only from speedstep_get_freqs, so it shouldn't cause any problem. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> --- drivers/cpufreq/speedstep-lib.c | 3 +++ drivers/cpufreq/speedstep-smi.c | 12 ++++++++++++ 2 files changed, 15 insertions(+) Index: linux-next/drivers/cpufreq/speedstep-smi.c =================================================================== --- linux-next.orig/drivers/cpufreq/speedstep-smi.c 2014-01-14 22:26:59.000000000 +0100 +++ linux-next/drivers/cpufreq/speedstep-smi.c 2014-01-14 22:35:11.000000000 +0100 @@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned return; /* Disable IRQs */ + preempt_disable(); local_irq_save(flags); command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff); @@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned do { if (retry) { + /* + * We need to enable interrupts, otherwise the blockage + * won't resolve. + * + * We disable preemption so that other processes don't + * run. If other processes were running, they could + * submit more DMA requests, making the blockage worse. + */ pr_debug("retry %u, previous result %u, waiting...\n", retry, result); + local_irq_enable(); mdelay(retry * 50); + local_irq_disable(); } retry++; __asm__ __volatile__( @@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned /* enable IRQs */ local_irq_restore(flags); + preempt_enable(); if (new_state == state) pr_debug("change to %u MHz succeeded after %u tries " Index: linux-next/drivers/cpufreq/speedstep-lib.c =================================================================== --- linux-next.orig/drivers/cpufreq/speedstep-lib.c 2014-01-14 22:29:07.000000000 +0100 +++ linux-next/drivers/cpufreq/speedstep-lib.c 2014-01-14 22:31:04.000000000 +0100 @@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp pr_debug("previous speed is %u\n", prev_speed); + preempt_disable(); local_irq_save(flags); /* switch to low state */ @@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp out: local_irq_restore(flags); + preempt_enable(); + return ret; } EXPORT_SYMBOL_GPL(speedstep_get_freqs);
On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:
> On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> >
> > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> >
> > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > preempt_enable_no_resched() from modules")
> > >
> > > Read these two lines, then note that:
> > >
> > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > >
> > > this obviously will not work as preempt_check_resched() and
> > > preempt_enable_no_resched() are no longer available to modules.
> >
> > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to
> > linux-next, that broke my patch.
> >
> > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > patch is a very good idea.
> > > > >
> > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > interrupt is required for progress, and how does it make the progress
> > > > > happen.
> > > >
> > > > There is no explanation. It's hardware issue and I have no documentation
> > > > for the hardware.
> > >
> > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > hardware does/needs.
> > >
> > > > The general problem is that if there are bus-master transfers running (or
> > > > possibly for other hardware reasons), the CPU refuses to change frequency.
> > > > You can wait a little bit and retry and maybe you succeed changing the
> > > > frequency next time.
> > > >
> > > > If you enable interrupts, wait, disable interrupts and retry, you may
> > > > succeed. If you keep interrupts disabled and retry, you never succeed, no
> > > > matter how long do you wait. I found it experimentally, I don't know
> > > > reason for that.
> > >
> > > Sounds like magic goo..
> > >
> > > In any case, try the below, it does the same but is far less horrid.
> > >
> > > ---
> > > drivers/cpufreq/speedstep-smi.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > index 0f5326d6f79f..57d31538c248 100644
> > > --- a/drivers/cpufreq/speedstep-smi.c
> > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > > return;
> > >
> > > /* Disable IRQs */
> > > + preempt_disable();
> > > local_irq_save(flags);
> > >
> > > command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > > if (retry) {
> > > pr_debug("retry %u, previous result %u, waiting...\n",
> > > retry, result);
> > > + local_irq_restore(flags);
> >
> > ^^^ this is wrong, because the function speedstep_set_state may already be
> > called with interrupts disabled from speedstep_get_freqs. So, you need to
> > enable interrupts unconditionally, even if they were disabled at the
> > beginning of the function speedstep_set_state.
> >
> > I know it's dirty to enable interrupts in a function that was called with
> > disabled interrupts, but here it must be so (you could rewrite
> > speedstep_get_freqs to not disable interrupts if you want to avoid this
> > dirtiness).
> >
> > > mdelay(retry * 50);
> > > + local_irq_save(flags);
> > > }
> > > retry++;
> > > __asm__ __volatile__(
> > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > >
> > > /* enable IRQs */
> > > local_irq_restore(flags);
> > > + preempt_enable();
> > >
> > > if (new_state == state)
> > > pr_debug("change to %u MHz succeeded after %u tries "
> >
> > You need also preempt_disable/enable in speedstep_get_freqs.
> >
> >
> > Here I'm resending the patch, to account for
> > 62b94a08da1bae9d187d49dfcd6665af393750f8.
>
> Do I think correctly that this should work regardless of whether or not
> 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?
Yes.
Mikulas
On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote: > > On Tue, 14 Jan 2014, Peter Zijlstra wrote: > > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote: > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote: > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away > > > > > preempt_enable_no_resched() from modules") > > > > Read these two lines, then note that: > > > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help? > > > > this obviously will not work as preempt_check_resched() and > > preempt_enable_no_resched() are no longer available to modules. > > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to > linux-next, that broke my patch. > > > > > I think that pm commit is a very good example of why the sched/preempt > > > > patch is a very good idea. > > > > > > > > Also that Changelog fails to explain why enabling interrupts helps. What > > > > interrupt is required for progress, and how does it make the progress > > > > happen. > > > > > > There is no explanation. It's hardware issue and I have no documentation > > > for the hardware. > > > > Rafael works for Intel, he ought to be able to figure out wtf the > > hardware does/needs. > > > > > The general problem is that if there are bus-master transfers running (or > > > possibly for other hardware reasons), the CPU refuses to change frequency. > > > You can wait a little bit and retry and maybe you succeed changing the > > > frequency next time. > > > > > > If you enable interrupts, wait, disable interrupts and retry, you may > > > succeed. If you keep interrupts disabled and retry, you never succeed, no > > > matter how long do you wait. I found it experimentally, I don't know > > > reason for that. > > > > Sounds like magic goo.. > > > > In any case, try the below, it does the same but is far less horrid. > > > > --- > > drivers/cpufreq/speedstep-smi.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c > > index 0f5326d6f79f..57d31538c248 100644 > > --- a/drivers/cpufreq/speedstep-smi.c > > +++ b/drivers/cpufreq/speedstep-smi.c > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state) > > return; > > > > /* Disable IRQs */ > > + preempt_disable(); > > local_irq_save(flags); > > > > command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff); > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state) > > if (retry) { > > pr_debug("retry %u, previous result %u, waiting...\n", > > retry, result); > > + local_irq_restore(flags); > > ^^^ this is wrong, because the function speedstep_set_state may already be > called with interrupts disabled from speedstep_get_freqs. So, you need to > enable interrupts unconditionally, even if they were disabled at the > beginning of the function speedstep_set_state. > > I know it's dirty to enable interrupts in a function that was called with > disabled interrupts, but here it must be so (you could rewrite > speedstep_get_freqs to not disable interrupts if you want to avoid this > dirtiness). > > > mdelay(retry * 50); > > + local_irq_save(flags); > > } > > retry++; > > __asm__ __volatile__( > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state) > > > > /* enable IRQs */ > > local_irq_restore(flags); > > + preempt_enable(); > > > > if (new_state == state) > > pr_debug("change to %u MHz succeeded after %u tries " > > You need also preempt_disable/enable in speedstep_get_freqs. > > > Here I'm resending the patch, to account for > 62b94a08da1bae9d187d49dfcd6665af393750f8. Do I think correctly that this should work regardless of whether or not 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied? > From: Mikulas Patocka <mpatocka@redhat.com> > > speedstep-smi: enable interrupts when waiting > > On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the > speedstep-smi driver sometimes loads and sometimes doesn't load with > "change to state X failed" message. > > I found out that we need to enable interrupts while waiting. When we > enable interrupts, the blockage that prevents frequency transition > resolves and the transition is possible. With disabled interrupts, the > blockage doesn't resolve (no matter how long do we wait). > > This patch enables interrupts in the function speedstep_set_state that can > be called with disabled interrupts. However, this function is called with > disabled interrupts only from speedstep_get_freqs, so it shouldn't cause > any problem. > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> > > --- > drivers/cpufreq/speedstep-lib.c | 3 +++ > drivers/cpufreq/speedstep-smi.c | 12 ++++++++++++ > 2 files changed, 15 insertions(+) > > Index: linux-next/drivers/cpufreq/speedstep-smi.c > =================================================================== > --- linux-next.orig/drivers/cpufreq/speedstep-smi.c 2014-01-14 22:26:59.000000000 +0100 > +++ linux-next/drivers/cpufreq/speedstep-smi.c 2014-01-14 22:35:11.000000000 +0100 > @@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned > return; > > /* Disable IRQs */ > + preempt_disable(); > local_irq_save(flags); > > command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff); > @@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned > > do { > if (retry) { > + /* > + * We need to enable interrupts, otherwise the blockage > + * won't resolve. > + * > + * We disable preemption so that other processes don't > + * run. If other processes were running, they could > + * submit more DMA requests, making the blockage worse. > + */ > pr_debug("retry %u, previous result %u, waiting...\n", > retry, result); > + local_irq_enable(); > mdelay(retry * 50); > + local_irq_disable(); > } > retry++; > __asm__ __volatile__( > @@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned > > /* enable IRQs */ > local_irq_restore(flags); > + preempt_enable(); > > if (new_state == state) > pr_debug("change to %u MHz succeeded after %u tries " > Index: linux-next/drivers/cpufreq/speedstep-lib.c > =================================================================== > --- linux-next.orig/drivers/cpufreq/speedstep-lib.c 2014-01-14 22:29:07.000000000 +0100 > +++ linux-next/drivers/cpufreq/speedstep-lib.c 2014-01-14 22:31:04.000000000 +0100 > @@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp > > pr_debug("previous speed is %u\n", prev_speed); > > + preempt_disable(); > local_irq_save(flags); > > /* switch to low state */ > @@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp > > out: > local_irq_restore(flags); > + preempt_enable(); > + > return ret; > } > EXPORT_SYMBOL_GPL(speedstep_get_freqs); > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
On Tuesday, January 14, 2014 04:52:20 PM Mikulas Patocka wrote:
>
> On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:
>
> > On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> > >
> > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > >
> > > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > > preempt_enable_no_resched() from modules")
> > > >
> > > > Read these two lines, then note that:
> > > >
> > > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > > >
> > > > this obviously will not work as preempt_check_resched() and
> > > > preempt_enable_no_resched() are no longer available to modules.
> > >
> > > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to
> > > linux-next, that broke my patch.
> > >
> > > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > > patch is a very good idea.
> > > > > >
> > > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > > interrupt is required for progress, and how does it make the progress
> > > > > > happen.
> > > > >
> > > > > There is no explanation. It's hardware issue and I have no documentation
> > > > > for the hardware.
> > > >
> > > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > > hardware does/needs.
> > > >
> > > > > The general problem is that if there are bus-master transfers running (or
> > > > > possibly for other hardware reasons), the CPU refuses to change frequency.
> > > > > You can wait a little bit and retry and maybe you succeed changing the
> > > > > frequency next time.
> > > > >
> > > > > If you enable interrupts, wait, disable interrupts and retry, you may
> > > > > succeed. If you keep interrupts disabled and retry, you never succeed, no
> > > > > matter how long do you wait. I found it experimentally, I don't know
> > > > > reason for that.
> > > >
> > > > Sounds like magic goo..
> > > >
> > > > In any case, try the below, it does the same but is far less horrid.
> > > >
> > > > ---
> > > > drivers/cpufreq/speedstep-smi.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > > index 0f5326d6f79f..57d31538c248 100644
> > > > --- a/drivers/cpufreq/speedstep-smi.c
> > > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > > > return;
> > > >
> > > > /* Disable IRQs */
> > > > + preempt_disable();
> > > > local_irq_save(flags);
> > > >
> > > > command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > > > if (retry) {
> > > > pr_debug("retry %u, previous result %u, waiting...\n",
> > > > retry, result);
> > > > + local_irq_restore(flags);
> > >
> > > ^^^ this is wrong, because the function speedstep_set_state may already be
> > > called with interrupts disabled from speedstep_get_freqs. So, you need to
> > > enable interrupts unconditionally, even if they were disabled at the
> > > beginning of the function speedstep_set_state.
> > >
> > > I know it's dirty to enable interrupts in a function that was called with
> > > disabled interrupts, but here it must be so (you could rewrite
> > > speedstep_get_freqs to not disable interrupts if you want to avoid this
> > > dirtiness).
> > >
> > > > mdelay(retry * 50);
> > > > + local_irq_save(flags);
> > > > }
> > > > retry++;
> > > > __asm__ __volatile__(
> > > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > > >
> > > > /* enable IRQs */
> > > > local_irq_restore(flags);
> > > > + preempt_enable();
> > > >
> > > > if (new_state == state)
> > > > pr_debug("change to %u MHz succeeded after %u tries "
> > >
> > > You need also preempt_disable/enable in speedstep_get_freqs.
> > >
> > >
> > > Here I'm resending the patch, to account for
> > > 62b94a08da1bae9d187d49dfcd6665af393750f8.
> >
> > Do I think correctly that this should work regardless of whether or not
> > 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?
>
> Yes.
OK
I'll replace your original patch with this version, then.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
[-- Attachment #1: Type: text/plain, Size: 951 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/kernel/process.c: In function 'mwait_idle': /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration] __monitor((void *)¤t_thread_info()->flags, 0, 0); ^ arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration] __sti_mwait(0, 0); ^ Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait idle routines") interacting with commit 7760518cce95 ("x86 idle: restore mwait_idle()") from the idle tree. I am not sure how to fix this so I just reverted the idle tree commit for now (since it reverted cleanly). Please let me know if there is a better solution. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Tue, Jan 14, 2014 at 04:43:43PM -0500, Mikulas Patocka wrote: > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state) > > if (retry) { > > pr_debug("retry %u, previous result %u, waiting...\n", > > retry, result); > > + local_irq_restore(flags); > > ^^^ this is wrong, because the function speedstep_set_state may already be > called with interrupts disabled from speedstep_get_freqs. So, you need to > enable interrupts unconditionally, even if they were disabled at the > beginning of the function speedstep_set_state. > > I know it's dirty to enable interrupts in a function that was called with > disabled interrupts, but here it must be so (you could rewrite > speedstep_get_freqs to not disable interrupts if you want to avoid this > dirtiness). Egads; I think you had better, this is vile beyond reason. > > mdelay(retry * 50); > > + local_irq_save(flags); > > } > > retry++; > > __asm__ __volatile__( > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state) > > > > /* enable IRQs */ > > local_irq_restore(flags); > > + preempt_enable(); > > > > if (new_state == state) > > pr_debug("change to %u MHz succeeded after %u tries " > > You need also preempt_disable/enable in speedstep_get_freqs. Argh I see, this is really horrid. Anyway, its Rafael's call, its his subsystem he gets to fix it when it explodes. /me shudders
On Thu, Jan 16, 2014 at 02:58:29PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/kernel/process.c: In function 'mwait_idle': > /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration] > __monitor((void *)¤t_thread_info()->flags, 0, 0); > ^ > arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration] > __sti_mwait(0, 0); > ^ > > Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait > idle routines") interacting with commit 7760518cce95 ("x86 idle: restore > mwait_idle()") from the idle tree. > > I am not sure how to fix this so I just reverted the idle tree commit for > now (since it reverted cleanly). Please let me know if there is a better > solution. I think the below ought to work --- arch/x86/kernel/process.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 3fb8d95ab8b5..220df9b2f22a 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -28,6 +28,7 @@ #include <asm/fpu-internal.h> #include <asm/debugreg.h> #include <asm/nmi.h> +#include <asm/mwait.h> /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, @@ -398,6 +399,37 @@ static void amd_e400_idle(void) default_idle(); } +/* + * Intel Core2 and older machines prefer MWAIT over HALT for C1. + * We can't rely on cpuidle installing MWAIT, because it will not load + * on systems that support only C1 -- so the boot default must be MWAIT. + * + * Some AMD machines are the opposite, they depend on using HALT. + * + * So for default C1, which is used during boot until cpuidle loads, + * use MWAIT-C1 on Intel HW that has it, else use HALT. + */ +static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c) +{ + if (c->x86_vendor != X86_VENDOR_INTEL) + return 0; + + if (!cpu_has(c, X86_FEATURE_MWAIT)) + return 0; + + return 1; +} + +/* + * MONITOR/MWAIT with no hints, used for default default C1 state. + * This invokes MWAIT with interrutps enabled and no flags, + * which is backwards compatible with the original MWAIT implementation. + */ +static void mwait_idle(void) +{ + mwait_idle_with_hints(0, 0); +} + void select_idle_routine(const struct cpuinfo_x86 *c) { #ifdef CONFIG_SMP @@ -411,6 +443,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c) /* E400: APIC timer interrupt does not wake up CPU from C1e */ pr_info("using AMD E400 aware idle routine\n"); x86_idle = amd_e400_idle; + } else if (prefer_mwait_c1_over_halt(c)) { + pr_info("using mwait in idle threads\n"); + x86_idle = mwait_idle; } else x86_idle = default_idle; }
[-- Attachment #1: Type: text/plain, Size: 400 bytes --] Hi Peter, On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > I think the below ought to work To be clear, all you did was replace the body of mwait_idle() with mwait_idle_with_hints(0, 0); (and the comment above it)? I need to apply in incremental patch in the merge commit. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On 01/16/2014 04:19 AM, Peter Zijlstra wrote:
> + * MONITOR/MWAIT with no hints, used for default default C1 state.
The default default?
-hpa
On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote: > Hi Peter, > > On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > > > I think the below ought to work > > To be clear, all you did was replace the body of mwait_idle() with > > mwait_idle_with_hints(0, 0); Pretty much, and add the asm/mwait.h include, otherwise you'll end up with a compile fail. > (and the comment above it)? I need to apply in incremental patch in the > merge commit. I don't think I touched the comment at all.
[-- Attachment #1: Type: text/plain, Size: 760 bytes --] Hi Peter, On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote: > > > > On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > I think the below ought to work > > > > To be clear, all you did was replace the body of mwait_idle() with > > > > mwait_idle_with_hints(0, 0); > > Pretty much, and add the asm/mwait.h include, otherwise you'll end up > with a compile fail. > > > (and the comment above it)? I need to apply in incremental patch in the > > merge commit. > > I don't think I touched the comment at all. Thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> Hi Peter,
>
> On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> <peterz@infradead.org> wrote:
>>
>> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
>> wrote:
>>>
>>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
>>> <peterz@infradead.org> wrote:
>>>>
>>>> I think the below ought to work
>>>
>>> To be clear, all you did was replace the body of mwait_idle()
>>> with
>>>
>>> mwait_idle_with_hints(0, 0);
>>
>> Pretty much, and add the asm/mwait.h include, otherwise you'll
>> end up with a compile fail.
>>
>>> (and the comment above it)? I need to apply in incremental
>>> patch in the merge commit.
>>
>> I don't think I touched the comment at all.
>
In retrospect this bit probably should have gone through the idle
tree. That was my bad, I need to coordinate with Len better.
-hpa
[-- Attachment #1: Type: text/plain, Size: 2486 bytes --] Hi all, On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote: > > On 01/16/2014 02:34 PM, Stephen Rothwell wrote: > > > > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra > > <peterz@infradead.org> wrote: > >> > >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell > >> wrote: > >>> > >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra > >>> <peterz@infradead.org> wrote: > >>>> > >>>> I think the below ought to work > >>> > >>> To be clear, all you did was replace the body of mwait_idle() > >>> with > >>> > >>> mwait_idle_with_hints(0, 0); > >> > >> Pretty much, and add the asm/mwait.h include, otherwise you'll > >> end up with a compile fail. > >> > >>> (and the comment above it)? I need to apply in incremental > >>> patch in the merge commit. > >> > >> I don't think I touched the comment at all. > > > > In retrospect this bit probably should have gone through the idle > tree. That was my bad, I need to coordinate with Len better. So this is what I added as a merge fix patch. Someone just needs to make sure Linus gets this when the latter of the tow trees gets merged. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 17 Jan 2014 14:42:06 +1100 Subject: [PATCH] x86 idle: mwait_idle merge update Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/kernel/process.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index db471a87fdd8..4da840f01561 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -28,6 +28,7 @@ #include <asm/fpu-internal.h> #include <asm/debugreg.h> #include <asm/nmi.h> +#include <asm/mwait.h> /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, @@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c) static void mwait_idle(void) { - if (!need_resched()) { - if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) - clflush((void *)¤t_thread_info()->flags); - - __monitor((void *)¤t_thread_info()->flags, 0, 0); - smp_mb(); - if (!need_resched()) - __sti_mwait(0, 0); - else - local_irq_enable(); - } else - local_irq_enable(); + mwait_idle_with_hints(0, 0); } void select_idle_routine(const struct cpuinfo_x86 *c) -- 1.8.5.2 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Fri, 2014-01-17 at 14:45 +1100, Stephen Rothwell wrote: > Hi all, > > On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote: > > > > On 01/16/2014 02:34 PM, Stephen Rothwell wrote: > > > > > > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra > > > <peterz@infradead.org> wrote: > > >> > > >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell > > >> wrote: > > >>> > > >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra > > >>> <peterz@infradead.org> wrote: > > >>>> > > >>>> I think the below ought to work > > >>> > > >>> To be clear, all you did was replace the body of mwait_idle() > > >>> with > > >>> > > >>> mwait_idle_with_hints(0, 0); > > >> > > >> Pretty much, and add the asm/mwait.h include, otherwise you'll > > >> end up with a compile fail. > > >> > > >>> (and the comment above it)? I need to apply in incremental > > >>> patch in the merge commit. > > >> > > >> I don't think I touched the comment at all. > > > > > > > In retrospect this bit probably should have gone through the idle > > tree. That was my bad, I need to coordinate with Len better. > > So this is what I added as a merge fix patch. Someone just needs to make > sure Linus gets this when the latter of the tow trees gets merged. I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on Q6600 box. See below for an alternative. > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 17 Jan 2014 14:42:06 +1100 > Subject: [PATCH] x86 idle: mwait_idle merge update > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/kernel/process.c | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index db471a87fdd8..4da840f01561 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -28,6 +28,7 @@ > #include <asm/fpu-internal.h> > #include <asm/debugreg.h> > #include <asm/nmi.h> > +#include <asm/mwait.h> > > /* > * per-CPU TSS segments. Threads are completely 'soft' on Linux, > @@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c) > > static void mwait_idle(void) > { > - if (!need_resched()) { > - if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) > - clflush((void *)¤t_thread_info()->flags); > - > - __monitor((void *)¤t_thread_info()->flags, 0, 0); > - smp_mb(); > - if (!need_resched()) > - __sti_mwait(0, 0); > - else > - local_irq_enable(); > - } else > - local_irq_enable(); > + mwait_idle_with_hints(0, 0); > } > > void select_idle_routine(const struct cpuinfo_x86 *c) > -- > 1.8.5.2 idle: kill unnecessary mwait_idle() resched IPIs Set/clear polling instead. Q6600, pipe-test scheduling cross core: 3.8.13 487.2 KHz 1.000 3.13.0-master 415.5 KHz .852 3.13.0-master+ 415.2 KHz .852 + restore mwait_idle 3.13.0-master++ 488.5 KHz 1.002 + restore mwait_idle + IPI fix 3.13.0-next-20140117 -ENOBOOT 3.13.0-next-20140117+ 531.4 KHz 1.090 + IPI fix Signed-off-by: Mike Galbraith <bitbucket@online.de> --- arch/x86/include/asm/processor.h | 8 ++++++++ arch/x86/kernel/process.c | 10 +++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -723,6 +723,14 @@ static inline void sync_core(void) #endif } +static inline void __sti_mwait(unsigned long eax, unsigned long ecx) +{ + trace_hardirqs_on(); + /* "mwait %eax, %ecx;" */ + asm volatile("sti; .byte 0x0f, 0x01, 0xc9;" + :: "a" (eax), "c" (ecx)); +} + extern void select_idle_routine(const struct cpuinfo_x86 *c); extern void init_amd_e400_c1e_mask(void); --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -28,6 +28,7 @@ #include <asm/fpu-internal.h> #include <asm/debugreg.h> #include <asm/nmi.h> +#include <asm/mwait.h> /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, @@ -427,18 +428,21 @@ static int prefer_mwait_c1_over_halt(con static void mwait_idle(void) { - if (!need_resched()) { - if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) + if (!current_set_polling_and_test()) { + if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) { + mb(); clflush((void *)¤t_thread_info()->flags); + mb(); + } __monitor((void *)¤t_thread_info()->flags, 0, 0); - smp_mb(); if (!need_resched()) __sti_mwait(0, 0); else local_irq_enable(); } else local_irq_enable(); + current_clr_polling(); } void select_idle_routine(const struct cpuinfo_x86 *c)
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
disabled.
Could something like this work?
local_irq_enable();
mwait_idle_with_hints(0,0);
The interrupt enable window is slightly larger, but I'm not immediately
seeing a problem with that.
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
>
> Could something like this work?
>
> local_irq_enable();
> mwait_idle_with_hints(0,0);
>
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.
next-20140117 doesn't boot on my T7300 laptop either. I've tried the
two fixes, they both work for me.
Thanks,
--
Sabrina
On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
>
> Could something like this work?
>
> local_irq_enable();
> mwait_idle_with_hints(0,0);
>
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.
Yup, works just fine. Less is more.
Nice to see a _progression_ in the pipe too btw.
-Mike
On 01/18/2014 07:21 AM, Mike Galbraith wrote:
> On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
>> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box. See below for an alternative.
>>
>> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
>> disabled.
>>
>> Could something like this work?
>>
>> local_irq_enable();
>> mwait_idle_with_hints(0,0);
>>
>> The interrupt enable window is slightly larger, but I'm not immediately
>> seeing a problem with that.
>
> Yup, works just fine. Less is more.
>
> Nice to see a _progression_ in the pipe too btw.
>
This means an interrupt window is open and we can take an interrupt
between checking need_resched and the MWAIT, which couldn't happen with
__sti_mwait().
Are we sure that is actually safe?
-hpa
On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote: > >> Could something like this work? > >> > >> local_irq_enable(); > >> mwait_idle_with_hints(0,0); > >> > This means an interrupt window is open and we can take an interrupt > between checking need_resched and the MWAIT, which couldn't happen with > __sti_mwait(). > > Are we sure that is actually safe? current_set_polling_and_test() vs resched_task() should be good that way, but I've got a terrible head-ache today so don't rely on anything much I say.
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
> __monitor((void *)¤t_thread_info()->flags, 0, 0);
> ^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
> __sti_mwait(0, 0);
> ^
>
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
>
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.
IMO, a regression fix (restore mwait_idle()) is more important than a clean up
(restructure mwait routines), and the clean-up should take a back seat;
in -tip, in -next, upstream, and in -stable.
Also, I'm wondering if that clean-up went too far -- as not all users of mwait
are necessarily under the same conditions...
thanks,
Len Brown, Intel Open Source Technology Center
On 01/19/2014 05:00 PM, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> arch/x86/kernel/process.c: In function 'mwait_idle':
>> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>> __monitor((void *)¤t_thread_info()->flags, 0, 0);
>> ^
>> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>> __sti_mwait(0, 0);
>> ^
>>
>> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
>> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
>> mwait_idle()") from the idle tree.
>>
>> I am not sure how to fix this so I just reverted the idle tree commit for
>> now (since it reverted cleanly). Please let me know if there is a better
>> solution.
>
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.
>
> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...
>
Sounds like a NAK to me, in which case that bit should probably be
deferred and reintroduced after fixing via the idle tree?
-hpa
[-- Attachment #1: Type: text/plain, Size: 466 bytes --] On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: > > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > Q6600 box. See below for an alternative. > > idle: kill unnecessary mwait_idle() resched IPIs OK, so despite even further discussion, I have applied this as a merge fix patch for today. Let me know when it is all sorted out. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
+static void mwait_idle(void) +{ + mwait_idle_with_hints(0, 0); +} + The reason the patch above will crash Core2 machines is because core2 machines don't support mwait_idle_with_hints(). The calling sequence for old and new MWAIT instructions is different. The former must be invoked with interrupts enabled, and the later can be invoked with interrupts disabled, which is a feature that Linux takes advantage of. thanks, -Len
On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> +static void mwait_idle(void)
> +{
> + mwait_idle_with_hints(0, 0);
> +}
> +
>
> The reason the patch above will crash Core2 machines is because
> core2 machines don't support mwait_idle_with_hints().
>
> The calling sequence for old and new MWAIT instructions is different.
> The former must be invoked with interrupts enabled,
> and the later can be invoked with interrupts disabled,
> which is a feature that Linux takes advantage of.
What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
And your 'old' __sti_mwait(0,0) has the exact same arguments as
mwait_idle_with_hints(0,0).
On Sun, Jan 19, 2014 at 08:00:19PM -0500, Len Brown wrote: > On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > arch/x86/kernel/process.c: In function 'mwait_idle': > > /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration] > > __monitor((void *)¤t_thread_info()->flags, 0, 0); > > ^ > > arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration] > > __sti_mwait(0, 0); > > ^ > > > > Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait > > idle routines") interacting with commit 7760518cce95 ("x86 idle: restore > > mwait_idle()") from the idle tree. > > > > I am not sure how to fix this so I just reverted the idle tree commit for > > now (since it reverted cleanly). Please let me know if there is a better > > solution. > > IMO, a regression fix (restore mwait_idle()) is more important than a clean up > (restructure mwait routines), and the clean-up should take a back seat; > in -tip, in -next, upstream, and in -stable. It was part of that other regression fix, the 50+ watt thingy for your broken EX chips. It was also written much earlier and widely mailed and published before you did the core2 thing. > Also, I'm wondering if that clean-up went too far -- as not all users of mwait > are necessarily under the same conditions... Then make them so. The fact was that most of the mwait idle sites were bloody broken. And the single mwait_idle_with_hints() function presents a single nice function that does all the required magics.
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: >> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on >> Q6600 box. See below for an alternative. >> >> idle: kill unnecessary mwait_idle() resched IPIs > > OK, so despite even further discussion, I have applied this as a merge > fix patch for today. Let me know when it is all sorted out. > Where is this fix? ( Browsing Linux-next remote GIT repository online. ) 2x NOPE for me. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au
On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box. See below for an alternative.
>>>
>>> idle: kill unnecessary mwait_idle() resched IPIs
>>
>> OK, so despite even further discussion, I have applied this as a merge
>> fix patch for today. Let me know when it is all sorted out.
>>
>
> Where is this fix?
> ( Browsing Linux-next remote GIT repository online. )
> 2x NOPE for me.
>
> - Sedat -
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
> [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
>
Hmmm... Found this in Next/merge.log
+$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
+Applying: idle: kill unnecessary mwait_idle() resched IPIs
+$ git reset HEAD^
+Unstaged changes after reset:
+M arch/x86/include/asm/processor.h
+M arch/x86/kernel/process.c
Is this a local patch not shipped in the Linux-next (remote) GIT repo?
Why is this not in your next-fixes GIT repo?
A bit confused about your -next policies,
- Sedat -
On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
>> +static void mwait_idle(void)
>> +{
>> + mwait_idle_with_hints(0, 0);
>> +}
>> +
>>
>> The reason the patch above will crash Core2 machines is because
>> core2 machines don't support mwait_idle_with_hints().
>>
>> The calling sequence for old and new MWAIT instructions is different.
>> The former must be invoked with interrupts enabled,
>> and the later can be invoked with interrupts disabled,
>> which is a feature that Linux takes advantage of.
>
> What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
>
> And your 'old' __sti_mwait(0,0) has the exact same arguments as
> mwait_idle_with_hints(0,0).
>
The difference is the STI!
-hpa
On Mon, Jan 20, 2014 at 12:56:47AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> > On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> >> +static void mwait_idle(void)
> >> +{
> >> + mwait_idle_with_hints(0, 0);
> >> +}
> >> +
> >>
> >> The reason the patch above will crash Core2 machines is because
> >> core2 machines don't support mwait_idle_with_hints().
> >>
> >> The calling sequence for old and new MWAIT instructions is different.
> >> The former must be invoked with interrupts enabled,
> >> and the later can be invoked with interrupts disabled,
> >> which is a feature that Linux takes advantage of.
> >
> > What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
> >
> > And your 'old' __sti_mwait(0,0) has the exact same arguments as
> > mwait_idle_with_hints(0,0).
> >
>
> The difference is the STI!
So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
But that's entirely different from saying that core2 doesn't support
mwait_idle_with_hints because its a different instruction.
On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote: > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: > >> > >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > >> Q6600 box. See below for an alternative. > >> > >> idle: kill unnecessary mwait_idle() resched IPIs > > > > OK, so despite even further discussion, I have applied this as a merge > > fix patch for today. Let me know when it is all sorted out. > > > > Where is this fix? If you pull next-20140120, the fix is in it. > ( Browsing Linux-next remote GIT repository online. ) > 2x NOPE for me. Probably because it's a temporary conflict fix. -Mike
On 01/20/2014 01:16 AM, Peter Zijlstra wrote: >> >> The difference is the STI! > > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing. > No, that doesn't work. The point of __sti_mwait() is that the STI is the instruction immediately before the MWAIT, just like the combination STI;HLT. Since the execution of STI is always delayed by one instruction, these two instructions form an atomic unit, which means interrupts are enabled "after" we have entered MWAIT or HLT. > But that's entirely different from saying that core2 doesn't support > mwait_idle_with_hints because its a different instruction. If you think of STI;MWAIT as a "compound instruction" it kind of is. Newer CPUs don't have to play that trick anymore, because there is a flag to MWAIT which breaks us out of MWAIT on a pending interrupt without having to actually enable interrupts at the point of the MWAIT. -hpa
On Mon, Jan 20, 2014 at 10:17 AM, Mike Galbraith <bitbucket@online.de> wrote: > On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote: >> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: >> >> >> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on >> >> Q6600 box. See below for an alternative. >> >> >> >> idle: kill unnecessary mwait_idle() resched IPIs >> > >> > OK, so despite even further discussion, I have applied this as a merge >> > fix patch for today. Let me know when it is all sorted out. >> > >> >> Where is this fix? > > If you pull next-20140120, the fix is in it. > >> ( Browsing Linux-next remote GIT repository online. ) >> 2x NOPE for me. > > Probably because it's a temporary conflict fix. > It's about the handling of fixes for -next. For such kind of "special" tweaks Stephen introduced *next-fixes* (see his email on linux-next ML and [1]). Such make-my-system-boot-again and other critical fixes belong there. BTW, I found the merge hunk (see my other email). - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
* H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> >
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> >
>
> No, that doesn't work. The point of __sti_mwait() is that the STI
> is the instruction immediately before the MWAIT, just like the
> combination STI;HLT. Since the execution of STI is always delayed
> by one instruction, these two instructions form an atomic unit,
> which means interrupts are enabled "after" we have entered MWAIT or
> HLT.
>
> > But that's entirely different from saying that core2 doesn't
> > support mwait_idle_with_hints because its a different instruction.
>
> If you think of STI;MWAIT as a "compound instruction" it kind of is.
> Newer CPUs don't have to play that trick anymore, because there is a
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt
> without having to actually enable interrupts at the point of the
> MWAIT.
As a side note, at minimum the semantic and compatibility difference
needs to be _very_ clearly present in the naming. Something like
mwait_old_() or mwait_core2_(). That way such dependencies and
assumptions don't get lost in code restructuring, etc.
Thanks,
Ingo
On Mon, 2014-01-20 at 10:25 +0100, Sedat Dilek wrote:
> It's about the handling of fixes for -next.
Ah, it was a gripe in query form. My bad.
-Mike
On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> >
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> >
>
> No, that doesn't work. The point of __sti_mwait() is that the STI is
> the instruction immediately before the MWAIT, just like the combination
> STI;HLT. Since the execution of STI is always delayed by one
> instruction, these two instructions form an atomic unit, which means
> interrupts are enabled "after" we have entered MWAIT or HLT.
>
> > But that's entirely different from saying that core2 doesn't support
> > mwait_idle_with_hints because its a different instruction.
>
> If you think of STI;MWAIT as a "compound instruction" it kind of is.
> Newer CPUs don't have to play that trick anymore, because there is a
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt
> without having to actually enable interrupts at the point of the MWAIT.
Ok, so I still don't get the problem of enabling interrupts early.
If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not set NEED_RESCHED.
For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
and looped right back into it, so receiving those early -- before
actually calling MWAIT/HLT seems like a NO-OP.
For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
places.
- current_set_polling_and_test(), we test need_resched after telling
remote CPUs they don't need to send interrupts because we're polling
for it -- the remote cpus set NEED_RESCHED before testing if we're
polling for it.
- we test NEED_RESCHED after setting up the monitor and before calling
MWAIT. Therefore, if an interrupt would happen right before we call
MWAIT, the monitor is already set and the MWAIT does an immediate
exit.
AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.
On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> Then make them so. The fact was that most of the mwait idle sites
> were bloody broken. And the single mwait_idle_with_hints() function
> presents a single nice function that does all the required magics.
To stress this a bit more; have a look see at mwwait_idle_with_hints();
it does a whole lot of subtle magic.
- current_{set,clr}_polling*(), these are crucial in not missing and
wrecking NEED_RESCHED state.
- X86_FEATURE_CLFLUSH_MONTIOR quirk
- Does the monitor(); if (!need_resched()) mwait() thing.
All of those are required for a correct and functional idle loop. And
I've seen sites where any or all of the above were missing/broken.
Not unifying the lot into a simple usable function is just stupid --
history has shown people simply cannot be trusted to get this right.
On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
>> Then make them so. The fact was that most of the mwait idle sites
>> were bloody broken. And the single mwait_idle_with_hints() function
>> presents a single nice function that does all the required magics.
>
> To stress this a bit more; have a look see at mwwait_idle_with_hints();
> it does a whole lot of subtle magic.
>
> - current_{set,clr}_polling*(), these are crucial in not missing and
> wrecking NEED_RESCHED state.
>
> - X86_FEATURE_CLFLUSH_MONTIOR quirk
>
> - Does the monitor(); if (!need_resched()) mwait() thing.
>
> All of those are required for a correct and functional idle loop. And
> I've seen sites where any or all of the above were missing/broken.
>
> Not unifying the lot into a simple usable function is just stupid --
> history has shown people simply cannot be trusted to get this right.
>
I don't think anyone is arguing that. The question is rather if the
implementation is correct, and if it is ready for the merge window.
-hpa
On 01/20/2014 01:55 AM, Peter Zijlstra wrote: > > Ok, so I still don't get the problem of enabling interrupts early. > > If we enable them early we can get interrupts; which afaict fall into > two groups, those that do and do not set NEED_RESCHED. > > For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT > and looped right back into it, so receiving those early -- before > actually calling MWAIT/HLT seems like a NO-OP. The description for commit d331e739f5ad seems to indicate otherwise: Idle callbacks has some races when enter_idle() sets isidle and subsequent interrupts that can happen on that CPU, before CPU goes to idle. Due to this, an IDLE_END can get called before IDLE_START. To avoid these races, disable interrupts before enter_idle and make sure that all idle routines do not enable interrupts before entering idle. This implies to me that once we have set isidle, if we take an interrupt we *have* to drop out of the idle routine. > For those setting NEED_RESCHED, we test NEED_RESCHED in all the right > places. > > - current_set_polling_and_test(), we test need_resched after telling > remote CPUs they don't need to send interrupts because we're polling > for it -- the remote cpus set NEED_RESCHED before testing if we're > polling for it. > > - we test NEED_RESCHED after setting up the monitor and before calling > MWAIT. Therefore, if an interrupt would happen right before we call > MWAIT, the monitor is already set and the MWAIT does an immediate > exit. > > AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way. > Well, it is obviously needed for the HLT case. For MWAIT it seems like the MONITOR should have gotten disarmed and therefore MWAIT shouldn't sleep... I don't know off the top of my head if there are any errata in that department and/or if there are any other issues. -hpa
On Mon, Jan 20, 2014 at 03:00:29AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> >
> > Ok, so I still don't get the problem of enabling interrupts early.
> >
> > If we enable them early we can get interrupts; which afaict fall into
> > two groups, those that do and do not set NEED_RESCHED.
> >
> > For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> > and looped right back into it, so receiving those early -- before
> > actually calling MWAIT/HLT seems like a NO-OP.
>
> The description for commit d331e739f5ad seems to indicate otherwise:
>
> Idle callbacks has some races when enter_idle() sets isidle and
> subsequent
> interrupts that can happen on that CPU, before CPU goes to idle. Due
> to this,
> an IDLE_END can get called before IDLE_START. To avoid these races,
> disable
> interrupts before enter_idle and make sure that all idle routines do not
> enable interrupts before entering idle.
>
> This implies to me that once we have set isidle, if we take an interrupt
> we *have* to drop out of the idle routine.
I don't think that applies anymore; the generic idle loop calls
arch_cpu_idle_enter() before calling arch_cpu_idle() where we would do
the enable.
So in that sense its impossible to get arch_cpu_idle_exit() -- or rather
exit_idle() as called from the interrupts -- to happen before
arch_cpu_idle_enter().
On Mon, Jan 20, 2014 at 02:19:30AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> > On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> >> Then make them so. The fact was that most of the mwait idle sites
> >> were bloody broken. And the single mwait_idle_with_hints() function
> >> presents a single nice function that does all the required magics.
> >
> > To stress this a bit more; have a look see at mwwait_idle_with_hints();
> > it does a whole lot of subtle magic.
> >
> > - current_{set,clr}_polling*(), these are crucial in not missing and
> > wrecking NEED_RESCHED state.
> >
> > - X86_FEATURE_CLFLUSH_MONTIOR quirk
> >
> > - Does the monitor(); if (!need_resched()) mwait() thing.
> >
> > All of those are required for a correct and functional idle loop. And
> > I've seen sites where any or all of the above were missing/broken.
> >
> > Not unifying the lot into a simple usable function is just stupid --
> > history has shown people simply cannot be trusted to get this right.
> >
>
> I don't think anyone is arguing that. The question is rather if the
> implementation is correct, and if it is ready for the merge window.
I've yet to hear an argument against it other than vaguaries.
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --] Hi Sedat, On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: > >>> > >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > >>> Q6600 box. See below for an alternative. > >>> > >>> idle: kill unnecessary mwait_idle() resched IPIs > >> > >> OK, so despite even further discussion, I have applied this as a merge > >> fix patch for today. Let me know when it is all sorted out. > >> > > > > Where is this fix? > > ( Browsing Linux-next remote GIT repository online. ) > > 2x NOPE for me. > > > > - Sedat - > > > > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle > > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git > > > > Hmmm... Found this in Next/merge.log > > +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch > +Applying: idle: kill unnecessary mwait_idle() resched IPIs > +$ git reset HEAD^ > +Unstaged changes after reset: > +M arch/x86/include/asm/processor.h > +M arch/x86/kernel/process.c You missed the next three lines: $ git add -A . $ git commit -v -a --amend [master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest' > Is this a local patch not shipped in the Linux-next (remote) GIT repo? > Why is this not in your next-fixes GIT repo? Its part of the conflict resolution for the merge of the tip tree. It cannot go into my fixes tree - that is for fixes to bugs in Linus' tree until they are integrated there. The tip and pm trees are both fine on their own, but combined they don't. So this fix has to go into the actual merge commit for the merge of the later tree. When Linus' merges the later of these trees he will also need this fix - or a better one - which is what is still under discussion. > A bit confused about your -next policies, Any better? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Mon, Jan 20, 2014 at 2:10 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Sedat, > > On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote: >> >> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote: >> >>> >> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on >> >>> Q6600 box. See below for an alternative. >> >>> >> >>> idle: kill unnecessary mwait_idle() resched IPIs >> >> >> >> OK, so despite even further discussion, I have applied this as a merge >> >> fix patch for today. Let me know when it is all sorted out. >> >> >> > >> > Where is this fix? >> > ( Browsing Linux-next remote GIT repository online. ) >> > 2x NOPE for me. >> > >> > - Sedat - >> > >> > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle >> > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git >> > >> >> Hmmm... Found this in Next/merge.log >> >> +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch >> +Applying: idle: kill unnecessary mwait_idle() resched IPIs >> +$ git reset HEAD^ >> +Unstaged changes after reset: >> +M arch/x86/include/asm/processor.h >> +M arch/x86/kernel/process.c > > You missed the next three lines: > > $ git add -A . > $ git commit -v -a --amend > [master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest' > [ I was absent for a while from Linux-next, so I am asking for clarification. ] [ I might be wrong. ] What does that mean? AFAICS you applied an important fix by yourself on top of tip/auto-latest? >> Is this a local patch not shipped in the Linux-next (remote) GIT repo? >> Why is this not in your next-fixes GIT repo? > > Its part of the conflict resolution for the merge of the tip tree. It > cannot go into my fixes tree - that is for fixes to bugs in Linus' tree > until they are integrated there. The tip and pm trees are both fine on > their own, but combined they don't. So this fix has to go into the actual > merge commit for the merge of the later tree. When Linus' merges the > later of these trees he will also need this fix - or a better one - which > is what is still under discussion. > I was asking in general about next-fixes to have a "bootable" (aka working) Linux-next kernel. You see next-fixes as a place to fix Linus-tree, seriously? The question here in this special case seems to be a "logical" (not-working-together) problem between tip and pm. And we are in a merge-window... >> A bit confused about your -next policies, > > Any better? > Not really. You should clarify on what you are doing in your next-fixes tree. Your daily report for Linux-next releases even does not mention next-fixes. Looking through my INBOX Thierry had the initial idea of "fixes for linux-next" when you were on vacation and he took over maintainership. - Sedat -
> As a side note, at minimum the semantic and compatibility difference
> needs to be _very_ clearly present in the naming. Something like
> mwait_old_() or mwait_core2_(). That way such dependencies and
> assumptions don't get lost in code restructuring, etc.
Agreed.
We started with mwait_idle() -- which was erroneously removed
and is now being restored under it original name.
The "new" function is mwait_idle_with_hints() -- which uses
the additional hints that were not available w/ the original MWAIT instruction.
Where "new" is Core Duo and later -- all the processor that can use
MWAIT for C-states deeper than C1.
Len Brown, Intel Open Source Technology Center
On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > As a side note, at minimum the semantic and compatibility difference
> > needs to be _very_ clearly present in the naming. Something like
> > mwait_old_() or mwait_core2_(). That way such dependencies and
> > assumptions don't get lost in code restructuring, etc.
>
> Agreed.
> We started with mwait_idle() -- which was erroneously removed
> and is now being restored under it original name.
>
> The "new" function is mwait_idle_with_hints() -- which uses
> the additional hints that were not available w/ the original MWAIT instruction.
> Where "new" is Core Duo and later -- all the processor that can use
> MWAIT for C-states deeper than C1.
I'm still waiting for someone to explain what's wrong with:
static inline void mwait_idle(void)
{
local_irq_enable();
mwait_idle_with_hints(0, 0);
}
On Mon, 2014-01-20 at 22:51 +0100, Peter Zijlstra wrote: > I'm still waiting for someone to explain what's wrong with: > > static inline void mwait_idle(void) > { > local_irq_enable(); > mwait_idle_with_hints(0, 0); > } How about just do that going forward, it work, and can always be fixed if something turns up, and the below for stable once it hits mainline? Q6600 box is happy camper in all trees. From: Len Brown <len.brown@intel.com> x86 idle: restore mwait_idle() In Linux-3.9 we removed the mwait_idle() loop: 'x86 idle: remove mwait_idle() and "idle=mwait" cmdline param' (69fb3676df3329a7142803bb3502fa59dc0db2e3) The reasoning was that modern machines should be sufficiently happy during the boot process using the default_idle() HALT loop, until cpuidle loads and either acpi_idle or intel_idle invoke the newer MWAIT-with-hints idle loop. But two machines reported problems: 1. Certain Core2-era machines support MWAIT-C1 and HALT only. MWAIT-C1 is preferred for optimal power and performance. But if they support just C1, cpuidle never loads and so they use the boot-time default idle loop forever. 2. Some laptops will boot-hang if HALT is used, but will boot successfully if MWAIT is used. This appears to be a hidden assumption in BIOS SMI, that is presumably valid on the proprietary OS where the BIOS was validated. https://bugzilla.kernel.org/show_bug.cgi?id=60770 So here we effectively revert the patch above, restoring the mwait_idle() loop. However, we don't bother restoring the idle=mwait cmdline parameter, since it appears to add no value. Maintainer notes: For 3.9, simply revert 69fb3676df for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context For 3.11, 3.12, 3.13, this patch applies cleanly Mike: reinstate polling, and add clflush barriers. Cc: Mike Galbraith <bitbucket@online.de> Cc: Ian Malone <ibmalone@gmail.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: <stable@vger.kernel.org> # 3.9, 3.10, 3.11, 3.12, 3.13 Signed-off-by: Mike Galbraith <bitbucket@online.de> Signed-off-by: Len Brown <len.brown@intel.com> --- diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 3fb8d95ab8b5..c5db2a43e730 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -398,6 +398,52 @@ static void amd_e400_idle(void) default_idle(); } +/* + * Intel Core2 and older machines prefer MWAIT over HALT for C1. + * We can't rely on cpuidle installing MWAIT, because it will not load + * on systems that support only C1 -- so the boot default must be MWAIT. + * + * Some AMD machines are the opposite, they depend on using HALT. + * + * So for default C1, which is used during boot until cpuidle loads, + * use MWAIT-C1 on Intel HW that has it, else use HALT. + */ +static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c) +{ + if (c->x86_vendor != X86_VENDOR_INTEL) + return 0; + + if (!cpu_has(c, X86_FEATURE_MWAIT)) + return 0; + + return 1; +} + +/* + * MONITOR/MWAIT with no hints, used for default default C1 state. + * This invokes MWAIT with interrutps enabled and no flags, + * which is backwards compatible with the original MWAIT implementation. + */ + +static void mwait_idle(void) +{ + if (!current_set_polling_and_test()) { + if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) { + mb(); + clflush((void *)¤t_thread_info()->flags); + mb(); + } + + __monitor((void *)¤t_thread_info()->flags, 0, 0); + if (!need_resched()) + __sti_mwait(0, 0); + else + local_irq_enable(); + } else + local_irq_enable(); + __current_clr_polling(); +} + void select_idle_routine(const struct cpuinfo_x86 *c) { #ifdef CONFIG_SMP @@ -411,6 +457,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c) /* E400: APIC timer interrupt does not wake up CPU from C1e */ pr_info("using AMD E400 aware idle routine\n"); x86_idle = amd_e400_idle; + } else if (prefer_mwait_c1_over_halt(c)) { + pr_info("using mwait in idle threads\n"); + x86_idle = mwait_idle; } else x86_idle = default_idle; }
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > > As a side note, at minimum the semantic and compatibility difference
> > > needs to be _very_ clearly present in the naming. Something like
> > > mwait_old_() or mwait_core2_(). That way such dependencies and
> > > assumptions don't get lost in code restructuring, etc.
> >
> > Agreed.
> > We started with mwait_idle() -- which was erroneously removed
> > and is now being restored under it original name.
> >
> > The "new" function is mwait_idle_with_hints() -- which uses the
> > additional hints that were not available w/ the original MWAIT
> > instruction. Where "new" is Core Duo and later -- all the
> > processor that can use MWAIT for C-states deeper than C1.
>
> I'm still waiting for someone to explain what's wrong with:
>
> static inline void mwait_idle(void)
> {
> local_irq_enable();
> mwait_idle_with_hints(0, 0);
> }
Absolutely agreed, we don't want to carry it on 'just because', the
compatibility aspect needs to be documented - otherwise we degrade
into cargo cult programming.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 918 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: "MAX_USER_PRIO" redefined [-Werror] #define MAX_USER_PRIO (MAX_PRIO - MAX_RT_PRIO) ^ In file included from include/linux/sched.h:6:0, from arch/powerpc/platforms/cell/spufs/sched.c:26: include/linux/sched/prio.h:38:0: note: this is the location of the previous definition #define MAX_USER_PRIO (USER_PRIO(MAX_PRIO)) ^ Caused by commit 6b6350f155af ("sched: Expose some macros related to priority"). A quick grep shows that MAX_USER_PRIO is defined in include/linux/sched/prio.h, but not used anywhere (except in arch/powerpc/platforms/cell/spufs/sched.c where it is also defined)? I have used the tip tree from next-20140210 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 861 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog': drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration] ppc64_runlatch_off(); ^ drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog': drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration] ppc64_runlatch_on(); ^ Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant cpuidle_idle_call()"). I have used the tip tree from next-20140210 again today (since next-20140211 was broken differently). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Hi Stephen, On 02/12/2014 08:11 AM, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog': > drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration] > ppc64_runlatch_off(); > ^ > drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog': > drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration] > ppc64_runlatch_on(); > ^ > > Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant > cpuidle_idle_call()"). Ok so after the commit d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call() reintroduced ppc64_runlatch_off/on() in drivers/cpuidle/cpuidle-pseries.c the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle: Remove redundant call to ppc64_runlatch_off() in cpu idle routines" now needs to be introduced in part. Below is the patch which should fix this. This is based on top of tip-tree. Thanks Regards Preeti U Murthy --------------------------------------------------------------------------------- cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend driver From: Preeti U Murthy <preeti@linux.vnet.ibm.com> Commit "d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()" reintroduced ppc64_runlatch_off/on() in the pseries cpuidle backend driver. Hence the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle: Remove redundant call to ppc64_runlatch_off() in cpu idle routines" in conjuction with the commit d8c6ad3184ca651 causes a build failure. Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> --- drivers/cpuidle/cpuidle-pseries.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c index d486489..6f7b019 100644 --- a/drivers/cpuidle/cpuidle-pseries.c +++ b/drivers/cpuidle/cpuidle-pseries.c @@ -17,6 +17,7 @@ #include <asm/reg.h> #include <asm/machdep.h> #include <asm/firmware.h> +#include <asm/runlatch.h> #include <asm/plpar_wrappers.h> struct cpuidle_driver pseries_idle_driver = { > > I have used the tip tree from next-20140210 again today (since > next-20140211 was broken differently). >
[-- Attachment #1: Type: text/plain, Size: 3636 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from arch/arm/include/asm/outercache.h:24:0, from arch/arm/include/asm/barrier.h:5, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:33, from include/linux/kernel.h:10, from include/asm-generic/bug.h:13, from arch/arm/include/asm/bug.h:61, from arch/arm/include/asm/div64.h:63, from include/linux/math64.h:5, from include/linux/jiffies.h:4, from init/calibrate.c:7: include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default] include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/bug.h: In function 'is_warning_bug': include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type In file included from include/linux/kernel.h:11:0, from include/asm-generic/bug.h:13, from arch/arm/include/asm/bug.h:61, from include/linux/bug.h:4, from arch/arm/include/asm/outercache.h:24, from arch/arm/include/asm/barrier.h:5, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:33, from include/linux/signal.h:35, from arch/arm/kernel/signal.c:12: include/linux/log2.h: In function '__ilog2_u32': include/linux/log2.h:34:2: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration] include/linux/log2.h: In function '__ilog2_u64': include/linux/log2.h:42:2: error: implicit declaration of function 'fls64' [-Werror=implicit-function-declaration] include/linux/log2.h: In function '__roundup_pow_of_two': include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long' [-Werror=implicit-function-declaration] In file included from include/linux/bitops.h:33:0, from include/linux/signal.h:35, from arch/arm/kernel/signal.c:12: arch/arm/include/asm/bitops.h: At top level: arch/arm/include/asm/bitops.h:273:19: error: static declaration of 'fls' follows non-static declaration include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here And many more ... Guessing ... caused by commit febdbfe8a91c ("arch: Prepare for smp_mb__ {before,after}_atomic()") and following interacting with commit 735e532e0f25 ("ARM: outer cache: add WARN_ON() to outer_disable()") from the arm tree? I applied this fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 24 Apr 2014 13:46:08 +1000 Subject: [PATCH] ARM: outer cache: remove include of linux/bug.h from outercache.h It causes a circular inclusion and looks like it is not necessary anyway. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/arm/include/asm/outercache.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h index eaa8a28c6871..891a56b35bcf 100644 --- a/arch/arm/include/asm/outercache.h +++ b/arch/arm/include/asm/outercache.h @@ -21,7 +21,6 @@ #ifndef __ASM_OUTERCACHE_H #define __ASM_OUTERCACHE_H -#include <linux/bug.h> #include <linux/types.h> struct outer_cache_fns { -- 2.0.0.rc0 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2397 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from arch/arm/include/asm/outercache.h:24:0, from arch/arm/include/asm/barrier.h:5, from arch/arm/include/asm/bitops.h:28, from include/linux/bitops.h:33, from include/linux/kernel.h:10, from include/asm-generic/bug.h:13, from arch/arm/include/asm/bug.h:61, from arch/arm/include/asm/div64.h:63, from include/linux/math64.h:5, from include/linux/jiffies.h:4, from init/calibrate.c:7: include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default] include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/bug.h: In function 'is_warning_bug': include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type ... and many, many more ... Probably caused by commit 030d0178bdbd ("arch,arm: Convert smp_mb__*()") which added an include of asm/barrier.h to arch/arm/include/asm/bitops.h. This has interacted with commit 59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()") from the arm tree, which adds an include of linux/bug.h to arch/arm/include/asm/outercache.h. I added the below merge fix patch. Russell, this should be applied to your tree directly. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 23 May 2014 17:10:12 +1000 Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h This fixes a cricular include dependency when combined with commits from the tip tree. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/arm/include/asm/outercache.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h index eaa8a28c6871..891a56b35bcf 100644 --- a/arch/arm/include/asm/outercache.h +++ b/arch/arm/include/asm/outercache.h @@ -21,7 +21,6 @@ #ifndef __ASM_OUTERCACHE_H #define __ASM_OUTERCACHE_H -#include <linux/bug.h> #include <linux/types.h> struct outer_cache_fns { -- 2.0.0.rc4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2644 bytes --] Hi Russell, On Fri, 23 May 2014 17:14:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from arch/arm/include/asm/outercache.h:24:0, > from arch/arm/include/asm/barrier.h:5, > from arch/arm/include/asm/bitops.h:28, > from include/linux/bitops.h:33, > from include/linux/kernel.h:10, > from include/asm-generic/bug.h:13, > from arch/arm/include/asm/bug.h:61, > from arch/arm/include/asm/div64.h:63, > from include/linux/math64.h:5, > from include/linux/jiffies.h:4, > from init/calibrate.c:7: > include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default] > include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] > include/linux/bug.h: In function 'is_warning_bug': > include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type > > ... and many, many more ... > > Probably caused by commit 030d0178bdbd ("arch,arm: Convert > smp_mb__*()") which added an include of asm/barrier.h to > arch/arm/include/asm/bitops.h. This has interacted with commit > 59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()") > from the arm tree, which adds an include of linux/bug.h to > arch/arm/include/asm/outercache.h. > > I added the below merge fix patch. Russell, this should be applied to > your tree directly. Ping? I am still carrying this patch ... > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 23 May 2014 17:10:12 +1000 > Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h > > This fixes a cricular include dependency when combined with commits from > the tip tree. > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/arm/include/asm/outercache.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h > index eaa8a28c6871..891a56b35bcf 100644 > --- a/arch/arm/include/asm/outercache.h > +++ b/arch/arm/include/asm/outercache.h > @@ -21,7 +21,6 @@ > #ifndef __ASM_OUTERCACHE_H > #define __ASM_OUTERCACHE_H > > -#include <linux/bug.h> > #include <linux/types.h> > > struct outer_cache_fns { > -- > 2.0.0.rc4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 757 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init': drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration] Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated setup_sched_clock() API") from the tip tree. The usage was only added to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock source for Versatile Express") (but this commit has been in linux-next since May 22 at least). I have reverted the tip tree commit for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
On Wed, 4 Jun 2014, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > > drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init': > drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration] > > Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated > setup_sched_clock() API") from the tip tree. The usage was only added > to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock > source for Versatile Express") (but this commit has been in linux-next > since May 22 at least). > > I have reverted the tip tree commit for today. Dammit. Why the heck can ARM folks not route their stuff through the relevant maintainers? Because ARM is a different universe with different rules or what? Of course this crap is already in Linus next branch, so it essentially blocks me from sending my pending timers/core branch. Patch below. Linus, can you please apply this? I've ranted about this before. It's not the first time that ARM breaks stuff I maintain. Again: Send your stuff against drivers/clocksource and drivers/irqchip to the maintainers. I'm happy to provide you a separate branch to pull that stuff from me, if you have dependencies on that, but I really don't want to see any of this again, ever. Yours seriously grumpy tglx ------------> Subject: clocksource: versatile: Use sched_clock_register() From: Thomas Gleixner <tglx@linutronix.de> Date: Wed, 04 Jun 2014 12:34:15 +0200 The newly merged versatile sched clock support uses a deprecated interface. Of course that patch got routed through the ARM tree instead of going through the relevant maintainer tree. Use the proper interface so we can get rid of the cruft. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c index e4c50ad..2798e74 100644 --- a/drivers/clocksource/versatile.c +++ b/drivers/clocksource/versatile.c @@ -20,7 +20,7 @@ static void __iomem *versatile_sys_24mhz; -static u32 notrace versatile_sys_24mhz_read(void) +static u64 notrace versatile_sys_24mhz_read(void) { return readl(versatile_sys_24mhz); } @@ -34,7 +34,7 @@ static void __init versatile_sched_clock_init(struct device_node *node) versatile_sys_24mhz = base + SYS_24MHZ; - setup_sched_clock(versatile_sys_24mhz_read, 32, 24000000); + sched_clock_register(versatile_sys_24mhz_read, 32, 24000000); } CLOCKSOURCE_OF_DECLARE(versatile, "arm,vexpress-sysreg", - versatile_sched_clock_init); + versatile_sched_clock_init);
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Patch below. Linus, can you please apply this?
Done.
Linus
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Wed, 4 Jun 2014, Stephen Rothwell wrote: > >> Hi all, >> >> After merging the tip tree, today's linux-next build (arm >> multi_v7_defconfig) failed like this: >> >> >> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init': >> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration] >> >> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated >> setup_sched_clock() API") from the tip tree. The usage was only added >> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock >> source for Versatile Express") (but this commit has been in linux-next >> since May 22 at least). >> >> I have reverted the tip tree commit for today. > > Dammit. Why the heck can ARM folks not route their stuff through the > relevant maintainers? Because ARM is a different universe with > different rules or what? We talked about this as late as February this year. It's has been a long-standing issue that we've struggled with how we should manage. When I talked to you about it (irqchip drivers at the time), you said you were in general fine with us merging driver patches when someone times out waiting on you to review/merge a patch. My concern at the time is that while we can look at the code of the patch and review that, we don't have the larger picture of what's going on in the subsystem. Which is what caused problems here, I'd say. So, we'll dial back and stop taking these patches through our tree without an explicit ack or shared branch from you (or Daniel on clocksource). Not a problem at all. > Of course this crap is already in Linus next branch, so it essentially > blocks me from sending my pending timers/core branch. We obviously never intended to cause any problems like these, and I apologize for that. On the other hand, it would have been a lot easier to handle had the code on your end landed a bit sooner than in the middle of the merge window. > Patch below. Linus, can you please apply this? > > I've ranted about this before. It's not the first time that ARM breaks > stuff I maintain. > > Again: Send your stuff against drivers/clocksource and drivers/irqchip > to the maintainers. > > I'm happy to provide you a separate branch to pull that stuff from me, > if you have dependencies on that, but I really don't want to see any > of this again, ever. > > Yours seriously grumpy Not much I can say besides what's above and that I owe you a few beers at the next conference. -Olof
On Wed, 4 Jun 2014, Olof Johansson wrote: > On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > So, we'll dial back and stop taking these patches through our tree > without an explicit ack or shared branch from you (or Daniel on > clocksource). Not a problem at all. I prefer the shared branch (for clocksource and irqchip) either from me or from Daniel(clocksource) / Jason (irqchip). That way you can proceed and we can do our unrelated changes without creating merge dependencies. > On the other hand, it would have been a lot easier > to handle had the code on your end landed a bit sooner than in the > middle of the merge window. I know. I was just burried in futex wreckage for almost a week... > Not much I can say besides what's above and that I owe you a few beers > at the next conference. Don't worry. I let off steam and all is good if we can avoid this in the future. Though I'm certainly up for a few beers :) Thanks, tglx
[-- Attachment #1: Type: text/plain, Size: 742 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old' void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm, ^ In file included from arch/powerpc/kernel/time.c:77:0: include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm, ^ Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"). I have used the tip tree from next-20140724 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 882 bytes --] Hi all, On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old' > void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm, > ^ > In file included from arch/powerpc/kernel/time.c:77:0: > include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here > extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm, > ^ > > Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"). > > I have used the tip tree from next-20140724 for today. Ping? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On 07/29/2014 04:56 PM, Stephen Rothwell wrote: > Hi all, > > On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> Hi all, >> >> After merging the tip tree, today's linux-next build (powerpc >> ppc64_defconfig) failed like this: >> >> arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old' >> void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm, >> ^ >> In file included from arch/powerpc/kernel/time.c:77:0: >> include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here >> extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm, >> ^ >> >> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"). >> >> I have used the tip tree from next-20140724 for today. > > Ping? So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo in update_vsyscall_old definition), but I've not heard anything from anyone on it. thanks -john
[-- Attachment #1: Type: text/plain, Size: 3082 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: arch/arm/kernel/vdso.c: In function 'tk_is_cntvct': arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr' if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0) ^ arch/arm/kernel/vdso.c: In function 'update_vsyscall': arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr' vdso_data->cs_cycle_last = tk->tkr.cycle_last; ^ arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr' vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec; ^ arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr' vdso_data->cs_mult = tk->tkr.mult; ^ arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr' vdso_data->cs_shift = tk->tkr.shift; ^ arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr' vdso_data->cs_mask = tk->tkr.mask; ^ Caused by commit 876e78818def ("time: Rename timekeeper::tkr to timekeeper::tkr_mono") from the tip tree interacting with commit ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and synchronization") from the arm tree. I added this merge fix patch for today (is that all that is needed?): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 30 Mar 2015 17:08:21 +1100 Subject: [PATCH] ARM: VDSO: rename tkr to tkr_mono Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/arm/kernel/vdso.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c index 0d31d3ccab81..efe17dd9b921 100644 --- a/arch/arm/kernel/vdso.c +++ b/arch/arm/kernel/vdso.c @@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk) if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER)) return false; - if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0) + if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0) return false; return true; @@ -316,12 +316,12 @@ void update_vsyscall(struct timekeeper *tk) vdso_data->wtm_clock_nsec = wtm->tv_nsec; if (vdso_data->tk_is_cntvct) { - vdso_data->cs_cycle_last = tk->tkr.cycle_last; + vdso_data->cs_cycle_last = tk->tkr_mono.cycle_last; vdso_data->xtime_clock_sec = tk->xtime_sec; - vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec; - vdso_data->cs_mult = tk->tkr.mult; - vdso_data->cs_shift = tk->tkr.shift; - vdso_data->cs_mask = tk->tkr.mask; + vdso_data->xtime_clock_snsec = tk->tkr_mono.xtime_nsec; + vdso_data->cs_mult = tk->tkr_mono.mult; + vdso_data->cs_shift = tk->tkr_mono.shift; + vdso_data->cs_mask = tk->tkr_mono.mask; } vdso_write_end(vdso_data); -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Mon, Mar 30, 2015 at 05:13:34PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
> arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr'
> if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
> ^
> arch/arm/kernel/vdso.c: In function 'update_vsyscall':
> arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr'
> vdso_data->cs_cycle_last = tk->tkr.cycle_last;
> ^
> arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr'
> vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
> ^
> arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr'
> vdso_data->cs_mult = tk->tkr.mult;
> ^
> arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr'
> vdso_data->cs_shift = tk->tkr.shift;
> ^
> arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr'
> vdso_data->cs_mask = tk->tkr.mask;
> ^
>
> Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
> timekeeper::tkr_mono") from the tip tree interacting with commit
> ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
> synchronization") from the arm tree.
>
> I added this merge fix patch for today (is that all that is needed?):
I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
tree.
The ARM VDSO stuff will just have to wait for 4.2 instead.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[-- Attachment #1: Type: text/plain, Size: 714 bytes --] Hi Russell, On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep > it in my tree and keep my tree buildable without dragging in the tip > tree. Does it affect your tree on its own? If not, then it can be fixed when merged as I have done, or if you look at the tip tree, all you really need to merge is tip timers/core branch (which I am sure the tip guys can tell you if it is stable enough) which is about 28 commits ... > The ARM VDSO stuff will just have to wait for 4.2 instead. If that works for you. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> Hi Russell,
>
> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>
>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>> it in my tree and keep my tree buildable without dragging in the tip
>> tree.
>
> Does it affect your tree on its own? If not, then it can be fixed when
> merged as I have done, or if you look at the tip tree, all you really
> need to merge is tip timers/core branch (which I am sure the tip guys
> can tell you if it is stable enough) which is about 28 commits ...
>
>> The ARM VDSO stuff will just have to wait for 4.2 instead.
>
> If that works for you.
FWIW, Stephen's merge fix is correct and I have run my vdso tests
without problems on OMAP5 with next-20150330.
On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > Hi Russell,
> >
> > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >>
> >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> >> it in my tree and keep my tree buildable without dragging in the tip
> >> tree.
> >
> > Does it affect your tree on its own? If not, then it can be fixed when
> > merged as I have done, or if you look at the tip tree, all you really
> > need to merge is tip timers/core branch (which I am sure the tip guys
> > can tell you if it is stable enough) which is about 28 commits ...
> >
> >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> >
> > If that works for you.
>
> FWIW, Stephen's merge fix is correct and I have run my vdso tests
> without problems on OMAP5 with next-20150330.
Hopefully, I can pull the tip stuff but if not, I'll try to remember
to include Stephen's patch with my pull request, but I can't make any
guarantees - Stephen's email will very quickly get buried in my mailbox,
and I'll most likely forget about it too... I'm notoriously bad with
email...
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
>> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
>>> Hi Russell,
>>>
>>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>>>
>>>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>>>> it in my tree and keep my tree buildable without dragging in the tip
>>>> tree.
>>>
>>> Does it affect your tree on its own? If not, then it can be fixed when
>>> merged as I have done, or if you look at the tip tree, all you really
>>> need to merge is tip timers/core branch (which I am sure the tip guys
>>> can tell you if it is stable enough) which is about 28 commits ...
>>>
>>>> The ARM VDSO stuff will just have to wait for 4.2 instead.
>>>
>>> If that works for you.
>>
>> FWIW, Stephen's merge fix is correct and I have run my vdso tests
>> without problems on OMAP5 with next-20150330.
>
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...
OK, let me know if I can help.
I'm happy to remind you about it when the merge window opens.
[-- Attachment #1: Type: text/plain, Size: 566 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: kernel/events/core.c: In function 'perf_event_set_bpf_prog': kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type' if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { ^ Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs attached to kprobes"). I have used the tip tree from next-20150402 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> ^
>
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").
Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?
Thanks,
Ingo
On Tue, Apr 07, 2015 at 05:18:58PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > kernel/events/core.c: In function 'perf_event_set_bpf_prog': > kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type' > if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > ^ > > Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs > attached to kprobes"). > > I have used the tip tree from next-20150402 for today. Hmm, tip/master builds fine on ppc64 for me, but does something like the below help? --- Subject: perf: Fix BPF filter crud The BPF filter crud got its CONFIG deps wrong, fix it. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- kernel/events/core.c | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 06917d5..1d94b92 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6711,6 +6711,25 @@ static void perf_event_free_filter(struct perf_event *event) ftrace_profile_free_filter(event); } +#else /* EVENT_TRACING */ + +static inline void perf_tp_register(void) +{ +} + +static int perf_event_set_filter(struct perf_event *event, void __user *arg) +{ + return -ENOENT; +} + +static void perf_event_free_filter(struct perf_event *event) +{ +} + +#endif /* EVENT_TRACING */ + +#if defined CONFIG_BPF_EVENTS && defined CONFIG_EVENT_TRACING + static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd) { struct bpf_prog *prog; @@ -6754,20 +6773,7 @@ static void perf_event_free_bpf_prog(struct perf_event *event) } } -#else - -static inline void perf_tp_register(void) -{ -} - -static int perf_event_set_filter(struct perf_event *event, void __user *arg) -{ - return -ENOENT; -} - -static void perf_event_free_filter(struct perf_event *event) -{ -} +#else /* BPF_EVENTS && EVENT_TRACING */ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd) { @@ -6777,7 +6783,8 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd) static void perf_event_free_bpf_prog(struct perf_event *event) { } -#endif /* CONFIG_EVENT_TRACING */ + +#endif /* BPF_EVENTS && EVENT_TRACING */ #ifdef CONFIG_HAVE_HW_BREAKPOINT void perf_bp_event(struct perf_event *bp, void *data)
On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>> ^
>>
>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>> attached to kprobes").
>
> Note, this must be some (rarely triggered) aspect of the ppc64
> defconfig that neither x86 randconfigs nor most other arch defconfigs
> expose?
Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
You should be able to resolve it in linux-next by changing the test to:
if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
Thanks,
Daniel
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --] Hi Daniel, On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 04/07/2015 10:48 AM, Ingo Molnar wrote: > > > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > >> After merging the tip tree, today's linux-next build (powerpc > >> ppc64_defconfig) failed like this: > >> > >> kernel/events/core.c: In function 'perf_event_set_bpf_prog': > >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type' > >> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > >> ^ > >> > >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs > >> attached to kprobes"). > > > > Note, this must be some (rarely triggered) aspect of the ppc64 > > defconfig that neither x86 randconfigs nor most other arch defconfigs > > expose? > > Note, this is a merge conflict with the work that went via net-next tree, > i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink > bpf_prog_aux"). I believe that is why it didn't trigger on tip tree. > > You should be able to resolve it in linux-next by changing the test to: > > if (prog->prog_type != BPF_PROG_TYPE_KPROBE) { Thanks Daniel, I will do that tomorrow. Someone will have to remember to tell Linus. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[ Cc'ing Dave, fyi ]
On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> After merging the tip tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) failed like this:
>>>>
>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>>>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>> ^
>>>>
>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>> attached to kprobes").
>>>
>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>> expose?
>>
>> Note, this is a merge conflict with the work that went via net-next tree,
>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>
>> You should be able to resolve it in linux-next by changing the test to:
>>
>> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>
> Thanks Daniel, I will do that tomorrow. Someone will have to remember
> to tell Linus.
Yes, indeed, depending which tree is merged first.
Thanks,
Daniel
On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> [ Cc'ing Dave, fyi ]
>
> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>> <daniel@iogearbox.net> wrote:
>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>> member named 'prog_type'
>>>>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>> ^
>>>>>
>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>> attached to kprobes").
>>>>
>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>> expose?
>>>
>>> Note, this is a merge conflict with the work that went via net-next
>>> tree,
>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>
>>> You should be able to resolve it in linux-next by changing the test to:
>>>
>>> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>
>> Thanks Daniel, I will do that tomorrow. Someone will have to remember
>> to tell Linus.
>
> Yes, indeed, depending which tree is merged first.
Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog->prog_type'
Thanks Stephen!
On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> On 4/7/15 4:13 AM, Daniel Borkmann wrote:
>> [ Cc'ing Dave, fyi ]
>>
>> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>>> <daniel@iogearbox.net> wrote:
>>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>
>>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>>> ppc64_defconfig) failed like this:
>>>>>>
>>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>>> member named 'prog_type'
>>>>>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>>> ^
>>>>>>
>>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>>> attached to kprobes").
>>>>>
>>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>>> expose?
>>>>
>>>> Note, this is a merge conflict with the work that went via net-next
>>>> tree,
>>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>>
>>>> You should be able to resolve it in linux-next by changing the test to:
>>>>
>>>> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>
>>> Thanks Daniel, I will do that tomorrow. Someone will have to remember
>>> to tell Linus.
>>
>> Yes, indeed, depending which tree is merged first.
>
> Daniel analysis is correct, but the fix for kernel/events/core.c
> should be:
> - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> instead of 'prog->prog_type'
Yes, absolutely, thanks!
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --] Hi all, On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote: > > On 4/7/15 4:13 AM, Daniel Borkmann wrote: > >> [ Cc'ing Dave, fyi ] > >> > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote: > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann > >>> <daniel@iogearbox.net> wrote: > >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote: > >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >>>>> > >>>>>> After merging the tip tree, today's linux-next build (powerpc > >>>>>> ppc64_defconfig) failed like this: > >>>>>> > >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog': > >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no > >>>>>> member named 'prog_type' > >>>>>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > >>>>>> ^ > >>>>>> > >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs > >>>>>> attached to kprobes"). > >>>>> > >>>>> Note, this must be some (rarely triggered) aspect of the ppc64 > >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs > >>>>> expose? > >>>> > >>>> Note, this is a merge conflict with the work that went via net-next > >>>> tree, > >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink > >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree. > >>>> > >>>> You should be able to resolve it in linux-next by changing the test to: > >>>> > >>>> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) { > >>> > >>> Thanks Daniel, I will do that tomorrow. Someone will have to remember > >>> to tell Linus. > >> > >> Yes, indeed, depending which tree is merged first. > > > > Daniel analysis is correct, but the fix for kernel/events/core.c > > should be: > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > > + if (prog->type != BPF_PROG_TYPE_KPROBE) { > > instead of 'prog->prog_type' > > Yes, absolutely, thanks! So I have applied that as a merge fix patch. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --] Hi Russell, On Mon, 30 Mar 2015 16:08:38 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote: > > On 03/30/2015 03:08 AM, Stephen Rothwell wrote: > > > Hi Russell, > > > > > > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > >> > > >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep > > >> it in my tree and keep my tree buildable without dragging in the tip > > >> tree. > > > > > > Does it affect your tree on its own? If not, then it can be fixed when > > > merged as I have done, or if you look at the tip tree, all you really > > > need to merge is tip timers/core branch (which I am sure the tip guys > > > can tell you if it is stable enough) which is about 28 commits ... > > > > > >> The ARM VDSO stuff will just have to wait for 4.2 instead. > > > > > > If that works for you. > > > > FWIW, Stephen's merge fix is correct and I have run my vdso tests > > without problems on OMAP5 with next-20150330. > > Hopefully, I can pull the tip stuff but if not, I'll try to remember > to include Stephen's patch with my pull request, but I can't make any > guarantees - Stephen's email will very quickly get buried in my mailbox, > and I'll most likely forget about it too... I'm notoriously bad with > email... This patch is now needed when the arm tree is merged with Linus' tree (the tip tree part has been merged). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --] Hi all, On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote: > > > On 4/7/15 4:13 AM, Daniel Borkmann wrote: > > >> [ Cc'ing Dave, fyi ] > > >> > > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote: > > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann > > >>> <daniel@iogearbox.net> wrote: > > >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote: > > >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > >>>>> > > >>>>>> After merging the tip tree, today's linux-next build (powerpc > > >>>>>> ppc64_defconfig) failed like this: > > >>>>>> > > >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog': > > >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no > > >>>>>> member named 'prog_type' > > >>>>>> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > > >>>>>> ^ > > >>>>>> > > >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs > > >>>>>> attached to kprobes"). > > >>>>> > > >>>>> Note, this must be some (rarely triggered) aspect of the ppc64 > > >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs > > >>>>> expose? > > >>>> > > >>>> Note, this is a merge conflict with the work that went via net-next > > >>>> tree, > > >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink > > >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree. > > >>>> > > >>>> You should be able to resolve it in linux-next by changing the test to: > > >>>> > > >>>> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) { > > >>> > > >>> Thanks Daniel, I will do that tomorrow. Someone will have to remember > > >>> to tell Linus. > > >> > > >> Yes, indeed, depending which tree is merged first. > > > > > > Daniel analysis is correct, but the fix for kernel/events/core.c > > > should be: > > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) { > > > + if (prog->type != BPF_PROG_TYPE_KPROBE) { > > > instead of 'prog->prog_type' > > > > Yes, absolutely, thanks! > > So I have applied that as a merge fix patch. This patch is now needed when the net-next tree is merged with Linus' tree. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1609 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/kernel.h:13:0, from include/linux/interrupt.h:5, from drivers/iommu/intel_irq_remapping.c:4: drivers/iommu/intel_irq_remapping.c: In function 'intel_enable_irq_remapping': drivers/iommu/intel_irq_remapping.c:656:48: error: 'eim' undeclared (first use in this function) pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic"); ^ Caused by my mismerge :-( I added this merge fix patch (and will fix the merge itself tomorrow): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 9 Jun 2015 17:12:00 +1000 Subject: [PATCH] iommu.vt-d: fix mismerge Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/iommu/intel_irq_remapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index 0d2500d17a2f..c19918471b3a 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -653,7 +653,7 @@ static int __init intel_enable_irq_remapping(void) irq_remapping_enabled = 1; - pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic"); + pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic"); return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE; -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
Hi all, After merging the tip tree, today's linux-next build (x86_allmodconfig) failed like this: drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_init_instr_queue': drivers/net/ethernet/cavium/liquidio/request_manager.c:111:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] iq->request_list = vmalloc(sizeof(*iq->request_list) * num_descs); ^ drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_delete_instr_queue': drivers/net/ethernet/cavium/liquidio/request_manager.c:178:3: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(iq->request_list); ^ drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 'octeon_free_device_mem': drivers/net/ethernet/cavium/liquidio/octeon_device.c:653:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(oct->droq[i]); ^ And so on. Caused by the interaction of commit d6472302f242 "x86/mm: Decouple <linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit f21fb3ed364b "Add support of Cavium Liquidio ethernet adapters" from the net-next tree. I applied the following fix for today: diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c index 2ca91657295f..4e581facae2c 100644 --- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c +++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c @@ -27,6 +27,7 @@ #include <linux/crc32.h> #include <linux/kthread.h> #include <linux/netdevice.h> +#include <linux/vmalloc.h> #include "octeon_config.h" #include "liquidio_common.h" #include "octeon_droq.h" diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c index 60a186f1609b..94b502a0cf33 100644 --- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c +++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c @@ -25,6 +25,7 @@ #include <linux/pci.h> #include <linux/kthread.h> #include <linux/netdevice.h> +#include <linux/vmalloc.h> #include "octeon_config.h" #include "liquidio_common.h" #include "octeon_droq.h" diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c b/drivers/net/ethernet/cavium/liquidio/request_manager.c index adb428463495..cd58660dd161 100644 --- a/drivers/net/ethernet/cavium/liquidio/request_manager.c +++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c @@ -26,6 +26,7 @@ #include <linux/pci.h> #include <linux/kthread.h> #include <linux/netdevice.h> +#include <linux/vmalloc.h> #include "octeon_config.h" #include "liquidio_common.h" #include "octeon_droq.h" cheers
From: "Chickles, Derek" <Derek.Chickles@caviumnetworks.com> Date: Fri, 12 Jun 2015 15:59:54 +0000 >> -----Original Message----- >> From: Michael Ellerman [mailto:mpe@ellerman.id.au] >> Sent: Friday, June 12, 2015 3:51 AM >> To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; David >> S.Miller >> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; >> sfr@canb.auug.org.au; Chickles, Derek; Burla, Satananda; Manlunas, Felix; >> Richter, Robert; Makarov, Aleksey; Vatsavayi, Raghu >> Subject: linux-next: build failure after merge of the tip tree >> >> Hi all, >> >> After merging the tip tree, today's linux-next build (x86_allmodconfig) >> failed like this: ... >> And so on. >> >> Caused by the interaction of commit d6472302f242 "x86/mm: Decouple >> <linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit >> f21fb3ed364b >> "Add support of Cavium Liquidio ethernet adapters" from the net-next tree. >> >> I applied the following fix for today: ... > Thanks. Much appreciated. This doesn't work, neither of these emails are a formal proper submission of a fix for this build failure. One of you has to do the work to formally submit the patch to netdev with a full signoff and commit log message so that it gets fixed in my tree. Thanks.
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> ...
> > Thanks. Much appreciated.
>
> This doesn't work, neither of these emails are a formal proper submission
> of a fix for this build failure.
>
> One of you has to do the work to formally submit the patch to netdev
> with a full signoff and commit log message so that it gets fixed in my
> tree.
>
> Thanks.
Yes, we're working on this. Hopefully, we'll have this submitted later today, with the build fix and sparse warning fixes.
[-- Attachment #1: Type: text/plain, Size: 727 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: kernel/cpu.c: In function '_cpu_down': kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration] irq_lock_sparse(); ^ kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration] irq_unlock_sparse(); ^ Caused by commit fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down") Forgot to include linux/irqdesc.h. I have used the tip tree from next-20150707 for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Wed, 8 Jul 2015, Stephen Rothwell wrote:
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/cpu.c: In function '_cpu_down':
> kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration]
> irq_lock_sparse();
> ^
> kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
> irq_unlock_sparse();
> ^
>
> Caused by commit
>
> fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down")
>
> Forgot to include linux/irqdesc.h.
>
> I have used the tip tree from next-20150707 for today.
Fixed in tip. Sorry for the hickup.
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/pinctrl/sirf/pinctrl-atlas7.c: In function 'atlas7_gpio_handle_irq': drivers/pinctrl/sirf/pinctrl-atlas7.c:4300:20: error: 'irq' undeclared (first use in this function) if (bank->irq == irq) ^ Caused by commit 5dc1aeb0340f ("pinctrl/sirf: Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch") [hmmm, not a wonderful commit summary line] I tried to use the tip tree from next-20150714, but for some reason that broke the perf build: BUILD: Doing 'make -j48' parallel build make[3]: *** No rule to make target '../lib/hweight.c', needed by '/scratch/sfr/next/tools/perf/util/hweight.o'. Stop. So instead, I applied the following fix patch for today's issue: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 15 Jul 2015 10:56:28 +1000 Subject: [PATCH] pinctrl/sirf: fix for Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/pinctrl/sirf/pinctrl-atlas7.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c index f55c931f1088..7917b7719939 100644 --- a/drivers/pinctrl/sirf/pinctrl-atlas7.c +++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c @@ -4294,6 +4294,7 @@ static void atlas7_gpio_handle_irq(unsigned int __irq, struct irq_desc *desc) u32 status, ctrl; int pin_in_bank = 0, idx; struct irq_chip *chip = irq_desc_get_chip(desc); + unsigned int irq = irq_desc_get_irq(desc); for (idx = 0; idx < a7gc->nbank; idx++) { bank = &a7gc->banks[idx]; -- 2.1.4 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq': arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration] gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | ^ Caused by commit e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode") from the mvebu tree interacting with commit 0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags") from the tip tree. I have applied the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 28 Jul 2015 12:26:21 +1000 Subject: [PATCH] irqchip/gic: merge fix for "Remove redundant gic_set_irqchip_flags" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/arm/mach-mvebu/board-v7.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c index a6d2b4d6701a..b5ef80f369e7 100644 --- a/arch/arm/mach-mvebu/board-v7.c +++ b/arch/arm/mach-mvebu/board-v7.c @@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr, static void __init mvebu_init_irq(void) { - struct device_node *np; - - np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-gic"); - if (np) - gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | - IRQCHIP_MASK_ON_SUSPEND); - of_node_put(np); irqchip_init(); mvebu_scu_enable(); coherency_init(); -- 2.4.6 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the tip tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic': drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration] par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); ^ drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); ^ Caused by commits 3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC") 8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default") The latter defines ioremap_uc() for x86 and those architectures that use asm-generic/io.h - which is not all of them :-( . The former commit then uses ioremap_uc(). I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it) for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi Stephen, On 28/07/15 03:43, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq': > arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration] > gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | > ^ > > Caused by commit > > e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode") > > from the mvebu tree interacting with commit > > 0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags") > > from the tip tree. > > I have applied the following merge fix patch for today: > Thanks for the fix, I was aware of this and asked Thomas Petazzoni and Gregory CLEMENT to revert the commit e6f134f8e30e if possible yesterday [1] Regards, Sudeep [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html
Hi Sudeep, Stephen, On 28/07/2015 10:41, Sudeep Holla wrote: > Hi Stephen, > > On 28/07/15 03:43, Stephen Rothwell wrote: >> Hi all, >> >> After merging the tip tree, today's linux-next build (arm >> multi_v7_defconfig) failed like this: >> >> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq': >> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration] >> gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | >> ^ >> >> Caused by commit >> >> e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode") >> >> from the mvebu tree interacting with commit >> >> 0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags") >> >> from the tip tree. >> >> I have applied the following merge fix patch for today: >> > > Thanks for the fix, I was aware of this and asked Thomas Petazzoni > and Gregory CLEMENT to revert the commit e6f134f8e30e if possible > yesterday [1] > I've just remove the commit from my branches, it should be OK now. Thanks, Gregory > Regards, > Sudeep > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic': > drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration] > par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); > ^ > drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast > par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); > ^ > > Caused by commits > > 3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC") > 8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default") > > The latter defines ioremap_uc() for x86 and those architectures that > use asm-generic/io.h - which is not all of them :-( . The former commit > then uses ioremap_uc(). > > I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it) > for today. This should be fixed by: http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb The way it was defined was to return NULL if an arch does not have it, *but* if the asm-generic io.h header is not included on some archs it will still fail, which leaves us no option but to then poke and define its implementaiton for archs which opt-out of asm-generic io.h Benh, in this case I believe its OK to to just map it to ioremap(), let me know what you think. diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index a8d2ef30d473..91db9153cd44 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size, unsigned long flags); extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size); #define ioremap_nocache(addr, size) ioremap((addr), (size)) +#define ioremap_uc(addr, size) ioremap((addr), (size)) extern void iounmap(volatile void __iomem *addr); Luis
On Tue, Jul 28, 2015 at 06:34:19PM +0200, Luis R. Rodriguez wrote: > On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the tip tree, today's linux-next build (powerpc > > allyesconfig) failed like this: > > > > drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic': > > drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration] > > par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); > > ^ > > drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast > > par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); > > ^ > > > > Caused by commits > > > > 3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC") > > 8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default") > > > > The latter defines ioremap_uc() for x86 and those architectures that > > use asm-generic/io.h - which is not all of them :-( . The former commit > > then uses ioremap_uc(). > > > > I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it) > > for today. > > This should be fixed by: > > http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb > > The way it was defined was to return NULL if an arch does not have it, > *but* if the asm-generic io.h header is not included on some archs it will still > fail, which leaves us no option but to then poke and define its implementaiton > for archs which opt-out of asm-generic io.h > > Benh, in this case I believe its OK to to just map it to ioremap(), let me know > what you think. > I checked and there are other architectures that do not include asm-generic/io.h, so here is the full patch fix, which I'll post next. From: "Luis R. Rodriguez" <mcgrof@suse.com> Subject: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures This adds ioremap_uc() only for architectures that do not include asm-generic.h/io.h as that already provides a default definition for them for both cases where you have CONFIG_MMU and you do not, and because of this, the number of architectures this patch address is less than the architectures that the ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to all architectures"). In order to reduce the number of architectures we have to modify by adding new architecture IO APIs we'll have to review the architectures in this patch, see why they can't add asm-generic.h/io.h or issues that would be created by doing so and then spread a consistent inclusion of this header towards the end of their own header. For instance arch/metag includes the asm-generic/io.h *before* the ioremap*() definitions, this should be the other way around but only once we have guard wrappers for the non-MMU case also for asm-generic/io.h. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/avr32/include/asm/io.h | 1 + arch/frv/include/asm/io.h | 1 + arch/m32r/include/asm/io.h | 1 + arch/m68k/include/asm/io_mm.h | 1 + arch/mn10300/include/asm/io.h | 1 + arch/powerpc/include/asm/io.h | 1 + arch/sh/include/asm/io.h | 1 + arch/tile/include/asm/io.h | 1 + 8 files changed, 8 insertions(+) diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h index e998ff5d8e1a..f855646e0db7 100644 --- a/arch/avr32/include/asm/io.h +++ b/arch/avr32/include/asm/io.h @@ -297,6 +297,7 @@ extern void __iounmap(void __iomem *addr); #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache +#define ioremap_uc ioremap_nocache #define cached(addr) P1SEGADDR(addr) #define uncached(addr) P2SEGADDR(addr) diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h index a31b63ec4930..70dfbea8c8d7 100644 --- a/arch/frv/include/asm/io.h +++ b/arch/frv/include/asm/io.h @@ -278,6 +278,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned l } #define ioremap_wc ioremap_nocache +#define ioremap_uc ioremap_nocache extern void iounmap(void volatile __iomem *addr); diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h index f8de767ce2bc..61b8931bc192 100644 --- a/arch/m32r/include/asm/io.h +++ b/arch/m32r/include/asm/io.h @@ -69,6 +69,7 @@ extern void iounmap(volatile void __iomem *addr); #define ioremap_nocache(off,size) ioremap(off,size) #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache +#define ioremap_uc ioremap_nocache /* * IO bus memory addresses are also 1:1 with the physical address diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h index f55cad529400..c98ac81582ac 100644 --- a/arch/m68k/include/asm/io_mm.h +++ b/arch/m68k/include/asm/io_mm.h @@ -468,6 +468,7 @@ static inline void __iomem *ioremap_nocache(unsigned long physaddr, unsigned lon { return __ioremap(physaddr, size, IOMAP_NOCACHE_SER); } +#define ioremap_uc ioremap_nocache static inline void __iomem *ioremap_wt(unsigned long physaddr, unsigned long size) { diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h index 07c5b4a3903b..62189353d2f6 100644 --- a/arch/mn10300/include/asm/io.h +++ b/arch/mn10300/include/asm/io.h @@ -283,6 +283,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache +#define ioremap_uc ioremap_nocache static inline void iounmap(void __iomem *addr) { diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index a8d2ef30d473..5879fde56f3c 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size, unsigned long flags); extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size); #define ioremap_nocache(addr, size) ioremap((addr), (size)) +#define ioremap_uc(addr, size) ioremap((addr), (size)) extern void iounmap(volatile void __iomem *addr); diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h index 728c4c571f40..93ec9066dbef 100644 --- a/arch/sh/include/asm/io.h +++ b/arch/sh/include/asm/io.h @@ -368,6 +368,7 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; } #endif #define ioremap_nocache ioremap +#define ioremap_uc ioremap #define iounmap __iounmap /* diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h index dc61de15c1f9..322b5fe94781 100644 --- a/arch/tile/include/asm/io.h +++ b/arch/tile/include/asm/io.h @@ -55,6 +55,7 @@ extern void iounmap(volatile void __iomem *addr); #define ioremap_nocache(physaddr, size) ioremap(physaddr, size) #define ioremap_wc(physaddr, size) ioremap(physaddr, size) #define ioremap_wt(physaddr, size) ioremap(physaddr, size) +#define ioremap_uc(physaddr, size) ioremap(physaddr, size) #define ioremap_fullcache(physaddr, size) ioremap(physaddr, size) #define mmiowb() -- 2.3.2.209.gd67f9d5.dirty
Hi all, After merging the tip tree, today's linux-next build (perf) failed like this: make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop. tools/build/Makefile.build:109: recipe for target 'arch' failed make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop. tools/build/Makefile.build:109: recipe for target 'fs' failed make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop. tools/build/Makefile.build:109: recipe for target 'util' failed Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed Makefile:68: recipe for target 'all' failed Maybe caused by commit 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects") This is an incremental build i.e. I do not do a "make clean" after doing the build for each tree merge (in case that matters). I have used the tip tree from next-20150915 for today. Also, building perf seems to ignore O=<dir> on the make invocation. Is that expected? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the next-20150915 version of the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/usb/gadget/function/u_ether.h:20:0, from drivers/usb/gadget/function/f_ncm.c:26: include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header' struct usb_cdc_parsed_header { ^ In file included from drivers/usb/gadget/function/f_ncm.c:24:0: include/linux/usb/cdc.h:23:8: note: originally defined here struct usb_cdc_parsed_header { ^ In file included from drivers/usb/gadget/function/u_ether.h:20:0, from drivers/usb/gadget/function/f_ncm.c:26: include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header' int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr, ^ In file included from drivers/usb/gadget/function/f_ncm.c:24:0: include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr, ^ In file included from drivers/usb/gadget/function/u_serial.h:16:0, from drivers/usb/gadget/legacy/cdc2.c:17: include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header' struct usb_cdc_parsed_header { ^ In file included from drivers/usb/gadget/function/u_ether.h:20:0, from drivers/usb/gadget/legacy/cdc2.c:16: include/linux/usb/cdc.h:23:8: note: originally defined here struct usb_cdc_parsed_header { ^ In file included from drivers/usb/gadget/function/u_serial.h:16:0, from drivers/usb/gadget/legacy/cdc2.c:17: include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header' int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr, ^ In file included from drivers/usb/gadget/function/u_ether.h:20:0, from drivers/usb/gadget/legacy/cdc2.c:16: include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr, ^ Caused by commit c40a2c8817e4 ("CDC: common parser for extra headers") from the net-next tree that added include/linux/usb/cdc.h with no reinclusion guards. I am not sure why I did not see this failure when building after merging the net-next tree. Maybe it is exposed by some config change in the tip tree? I have added the following fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 16 Sep 2015 11:10:16 +1000 Subject: [PATCH] cdc: add header guards Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/usb/cdc.h | 4 ++++ include/uapi/linux/usb/cdc.h | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h index 959d0c838113..b5706f94ee9e 100644 --- a/include/linux/usb/cdc.h +++ b/include/linux/usb/cdc.h @@ -7,6 +7,8 @@ * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. */ +#ifndef __LINUX_USB_CDC_H +#define __LINUX_USB_CDC_H #include <uapi/linux/usb/cdc.h> @@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr, struct usb_interface *intf, u8 *buffer, int buflen); + +#endif /* __LINUX_USB_CDC_H */ diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h index b6a9cdd6e096..e2bc417b243b 100644 --- a/include/uapi/linux/usb/cdc.h +++ b/include/uapi/linux/usb/cdc.h @@ -6,8 +6,8 @@ * firmware based USB peripherals. */ -#ifndef __LINUX_USB_CDC_H -#define __LINUX_USB_CDC_H +#ifndef __UAPI_LINUX_USB_CDC_H +#define __UAPI_LINUX_USB_CDC_H #include <linux/types.h> @@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size { #define USB_CDC_NCM_CRC_NOT_APPENDED 0x00 #define USB_CDC_NCM_CRC_APPENDED 0x01 -#endif /* __LINUX_USB_CDC_H */ +#endif /* __UAPI_LINUX_USB_CDC_H */ -- 2.5.1 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Sep 2015 11:30:53 +1000
> I have added the following fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (perf) failed > like this: > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop. > tools/build/Makefile.build:109: recipe for target 'arch' failed > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop. > tools/build/Makefile.build:109: recipe for target 'fs' failed > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop. > tools/build/Makefile.build:109: recipe for target 'util' failed > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed > Makefile:68: recipe for target 'all' failed > > Maybe caused by commit > > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects") > > This is an incremental build i.e. I do not do a "make clean" after doing > the build for each tree merge (in case that matters). it does in this case, removed header files stay in cmd build dependency file (like in .abspath.o.cmd above) and cause build error build system is not smart enough yet to find out, I was postponning fixing this for some time now, I'll try to get this resolved asap > > I have used the tip tree from next-20150915 for today. > > Also, building perf seems to ignore O=<dir> on the make invocation. > Is that expected? hum, not sure about this one.. I'm not using it, but we have tests for this and I thought we're ok.. I'll check jirka
On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> >
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> >
> > Maybe caused by commit
> >
> > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> >
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
>
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
>
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
>
> >
> > I have used the tip tree from next-20150915 for today.
> >
> > Also, building perf seems to ignore O=<dir> on the make invocation.
> > Is that expected?
>
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check
seems to work on latest Arnaldo's perf/core,
what command line failed for you?
[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
jirka
Hi Jiri,
On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> > > Also, building perf seems to ignore O=<dir> on the make invocation.
> > > Is that expected?
> >
> > hum, not sure about this one.. I'm not using it, but we have
> > tests for this and I thought we're ok.. I'll check
>
> seems to work on latest Arnaldo's perf/core,
> what command line failed for you?
>
> [jolsa@krava perf]$ make O=/tmp/krava/
> ...
> [jolsa@krava perf]$ ll /tmp/krava/perf
> -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
Thanks for the hint. I was using a relative path and starting in the
top of the kernel tree, so:
$ cd kernel
$ mkdir ../perf
$ make -s -C tools/perf JOBS=24 O=../perf
put everything in toos/perf (no suprise really)
I will change my script to use an absolute path (which I checked does
work fine). Sorry for the noise.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
Em Wed, Sep 16, 2015 at 05:30:25PM +1000, Stephen Rothwell escreveu: > Hi Jiri, > > On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote: > > > > > > Also, building perf seems to ignore O=<dir> on the make invocation. > > > > Is that expected? > > > > > > hum, not sure about this one.. I'm not using it, but we have > > > tests for this and I thought we're ok.. I'll check > > > > seems to work on latest Arnaldo's perf/core, > > what command line failed for you? > > > > [jolsa@krava perf]$ make O=/tmp/krava/ > > ... > > [jolsa@krava perf]$ ll /tmp/krava/perf > > -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf > > Thanks for the hint. I was using a relative path and starting in the > top of the kernel tree, so: > $ cd kernel > $ mkdir ../perf > $ make -s -C tools/perf JOBS=24 O=../perf > > put everything in toos/perf (no suprise really) > > I will change my script to use an absolute path (which I checked does > work fine). Sorry for the noise. Nice workaround, but I guess relative paths should be supported as well, right? :) - Arnaldo
Hi Jiri,
On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> >
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> >
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> >
> > Maybe caused by commit
> >
> > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> >
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
>
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
>
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge. It would be nice to have this fixed, though,
if possible.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
Hi all,
On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the tip tree, today's linux-next build (perf) failed
> > > like this:
> > >
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop.
> > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop.
> > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop.
> > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > Makefile:68: recipe for target 'all' failed
> > >
> > > Maybe caused by commit
> > >
> > > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > >
> > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > the build for each tree merge (in case that matters).
> >
> > it does in this case, removed header files stay in
> > cmd build dependency file (like in .abspath.o.cmd above)
> > and cause build error
> >
> > build system is not smart enough yet to find out,
> > I was postponning fixing this for some time now,
> > I'll try to get this resolved asap
>
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge. It would be nice to have this fixed, though,
> if possible.
I noticed some commits in the tip tree today that seemed as though they
were addressing this problem. However, I still get a build failure if
I don't clean out the object directory before building tools/perf:
BUILD: Doing 'make -j48' parallel build
GEN /home/sfr/next/perf/common-cmds.h
CC /home/sfr/next/perf/fixdep.o
LD /home/sfr/next/perf/fixdep-in.o
LINK /home/sfr/next/perf/fixdep
CC /home/sfr/next/perf/perf-read-vdso32
CC /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'. Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed
(/home/sfr/next/perf/ is the object directory)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
On Wed, Sep 30, 2015 at 12:56:40PM +1000, Stephen Rothwell wrote: > Hi all, > > On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote: > > > > > > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote: > > > > > > > > After merging the tip tree, today's linux-next build (perf) failed > > > > like this: > > > > > > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'. Stop. > > > > tools/build/Makefile.build:109: recipe for target 'arch' failed > > > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'. Stop. > > > > tools/build/Makefile.build:109: recipe for target 'fs' failed > > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'. Stop. > > > > tools/build/Makefile.build:109: recipe for target 'util' failed > > > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed > > > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed > > > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed > > > > Makefile:68: recipe for target 'all' failed > > > > > > > > Maybe caused by commit > > > > > > > > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects") > > > > > > > > This is an incremental build i.e. I do not do a "make clean" after doing > > > > the build for each tree merge (in case that matters). > > > > > > it does in this case, removed header files stay in > > > cmd build dependency file (like in .abspath.o.cmd above) > > > and cause build error > > > > > > build system is not smart enough yet to find out, > > > I was postponning fixing this for some time now, > > > I'll try to get this resolved asap > > > > OK, for now I will clean out my objdir before doing the perf build > > after the tip tree merge. It would be nice to have this fixed, though, > > if possible. > > I noticed some commits in the tip tree today that seemed as though they > were addressing this problem. However, I still get a build failure if > I don't clean out the object directory before building tools/perf: ouch, forgot to CC you, sry > > BUILD: Doing 'make -j48' parallel build > GEN /home/sfr/next/perf/common-cmds.h > CC /home/sfr/next/perf/fixdep.o > LD /home/sfr/next/perf/fixdep-in.o > LINK /home/sfr/next/perf/fixdep > CC /home/sfr/next/perf/perf-read-vdso32 > CC /home/sfr/next/perf/perf-read-vdsox32 > make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'. Stop. > /home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed > make[2]: *** [ui/gtk] Error 2 > Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed it won't fix the build if you still have old .cmd file in you tree (I presume that's the case), once those are regenerated you shouldn't meet the issue again jirka
Hi Jiri, On Wed, 30 Sep 2015 08:08:12 +0200 Jiri Olsa <jolsa@redhat.com> wrote: > > ouch, forgot to CC you, sry No worries, I was watching ... > it won't fix the build if you still have old .cmd file in you tree (I presume that's the case), > once those are regenerated you shouldn't meet the issue again Unfortunately this is what happens to me every day :-( (at least until these changes are merged into Linus' tree). Its fine, I have automated the clean up of the perf build object directory after merging the tip tree. However, this will also happen to anyone who has built perf then updates their tree and then tries to rebuild perf. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: DESCEND objtool CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o MKDIR /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/ CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o elf.c:22:23: fatal error: sys/types.h: No such file or directory compilation terminated. CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o builtin-check.c:28:20: fatal error: string.h: No such file or directory compilation terminated. objtool.c:28:19: fatal error: stdio.h: No such file or directory compilation terminated. and further errors ... This build is done with a PowerPC hosted cross compiler with no glibc. I assume that some things here need to be built with HOSTCC? Presumably caused by commit 9e54249679b4 ("Merge branch 'core/objtool'") and the commit series that was merged. I tried to revert that merge, but it had conflicts, so I just used the tip tree from next-20160229 for today. -- Cheers, Stephen Rothwell
* Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > DESCEND objtool > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o > MKDIR /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/ > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o > elf.c:22:23: fatal error: sys/types.h: No such file or directory > compilation terminated. > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o > CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o > builtin-check.c:28:20: fatal error: string.h: No such file or directory > compilation terminated. > objtool.c:28:19: fatal error: stdio.h: No such file or directory > compilation terminated. > > and further errors ... > > This build is done with a PowerPC hosted cross compiler with no glibc. Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next dependent on it? > I assume that some things here need to be built with HOSTCC? I suspect that's the culprit. Do you now mandate people to have PowerPC systems as a requirement to merge to linux-next? How are people supposed to be able to test that rare type of build method which does not matter to 99.99% of our kernel testers and users? Thanks, Ingo
On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> Hi all, >> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig) >> failed like this: >> >> DESCEND objtool >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o >> MKDIR /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/ >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o >> elf.c:22:23: fatal error: sys/types.h: No such file or directory >> compilation terminated. >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o >> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o >> builtin-check.c:28:20: fatal error: string.h: No such file or directory >> compilation terminated. >> objtool.c:28:19: fatal error: stdio.h: No such file or directory >> compilation terminated. >> >> and further errors ... >> >> This build is done with a PowerPC hosted cross compiler with no glibc. > > Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next > dependent on it? > >> I assume that some things here need to be built with HOSTCC? > > I suspect that's the culprit. Do you now mandate people to have PowerPC systems as > a requirement to merge to linux-next? How are people supposed to be able to test > that rare type of build method which does not matter to 99.99% of our kernel > testers and users? > >From my experience in using different $COMPILER you should always pass CC and HOSTCC in your make-line when building a Linux-kernel or playing with the Kconfig-system. When building my llvm-toolchain with make/autoconf I had also to pass CC and CXX to my configure-line otherwise you got misconfiguration. [ EXAMPLE: Linux Kconfig-system ] $ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER" $ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS silentoldconfig < /dev/null - Sedat -
On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>> DESCEND objtool
>>> CC
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>> CC
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>> CC
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>> MKDIR
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>> CC
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>> CC
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -
That is not the issue here. The problem is clearly that objtool is a host program and not compiled with host cc. So it is a good thing to test even though it is weird, because it affects real use cases.
As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
On Tue, Mar 1, 2016 at 8:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After merging the tip tree, today's linux-next build (x86_64
>>allmodconfig)
>>>> failed like this:
>>>>
>>>> DESCEND objtool
>>>> CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>> CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>> CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>> MKDIR
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>> CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>>> compilation terminated.
>>>> CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>>directory
>>>> compilation terminated.
>>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>>> compilation terminated.
>>>>
>>>> and further errors ...
>>>>
>>>> This build is done with a PowerPC hosted cross compiler with no
>>glibc.
>>>
>>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>>linux-next
>>> dependent on it?
>>>
>>>> I assume that some things here need to be built with HOSTCC?
>>>
>>> I suspect that's the culprit. Do you now mandate people to have
>>PowerPC systems as
>>> a requirement to merge to linux-next? How are people supposed to be
>>able to test
>>> that rare type of build method which does not matter to 99.99% of our
>>kernel
>>> testers and users?
>>>
>>
> >From my experience in using different $COMPILER you should always pass
>>CC and HOSTCC in your make-line when building a Linux-kernel or
>>playing with the Kconfig-system.
>>
>>When building my llvm-toolchain with make/autoconf I had also to pass
>>CC and CXX to my configure-line otherwise you got misconfiguration.
>>
>>[ EXAMPLE: Linux Kconfig-system ]
>>
>>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>>HOSTCC=$COMPILER"
>>
>>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>>silentoldconfig < /dev/null
>>
>>- Sedat -
>
> That is not the issue here. The problem is clearly that objtool is a host program and not compiled with host cc. So it is a good thing to test even though it is weird, because it affects real use cases.
>
> As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
>
Thanks for the clarification.
I talked about my experiences in software building in general.
When this is a "tools/objtool problem" then someone should address
this to "tools/objtool maintainers/folks" or whoever else is
responsible.
- Sedat -
Hi Ingo, On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar <mingo@kernel.org> wrote: > > > This build is done with a PowerPC hosted cross compiler with no glibc. > > Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next > dependent on it? It is just the fastest hardware I currently have access to (you remember who I work for, right? ;-)). I have always done at least part of the linux-next building (daily, or overnight) on PowerPC hardware and this is only the 2nd or third time in over 8 years that it has found an issue like this. > > I assume that some things here need to be built with HOSTCC? > > I suspect that's the culprit. Good, hopefully it is not too hard to fix. -- Cheers, Stephen Rothwell
* H. Peter Anvin <hpa@zytor.com> wrote:
> That is not the issue here. The problem is clearly that objtool is a host
> program and not compiled with host cc. So it is a good thing to test even
> though it is weird, because it affects real use cases.
Absolutely, it's a real bug that should be fixed. What is counterproductive is
that this rare and hard to replicate build modus is now a must-have test for
linux-next inclusion.
I already cross-build to 20+ weird, rarely used architectures, slowing down the
linux-next merge integration test immensely and wasting quite a bit of
electricity. linux-next making it even harder to test for is a step backwards.
Thanks,
Ingo
Hi all, After merging the tip tree, today's linux-next build (powerpc64le perf) failed like this: make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) Presumably caused by commit 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") I have reverted that commit for today (which fixes my build problem but may not be overall correct). -- Cheers, Stephen Rothwell
Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc64le perf) > failed like this: > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) I'll check, should've been caught by a cross compiler build for ppc64le I have in place :-\ minimal-ubuntu-x-ppc64el: Ok But maybe not, as this requires audit-libs-devel and that is not present on that minimal ubuntu x-compiler setup, sigh :-\ - Arnaldo > Presumably caused by commit > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") > > I have reverted that commit for today (which fixes my build problem but > may not be overall correct). > > -- > Cheers, > Stephen Rothwell
On Thu, 2016-04-14 at 09:35 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > > Hi all, > > > > After merging the tip tree, today's linux-next build (powerpc64le perf) > > failed like this: > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) > > I'll check, should've been caught by a cross compiler build for ppc64le > I have in place :-\ > > minimal-ubuntu-x-ppc64el: Ok > > But maybe not, as this requires audit-libs-devel and that is not present > on that minimal ubuntu x-compiler setup, sigh :-\ Hi acme, I have a jenkins which builds perf on ppc64le, but it only builds Linus' tree and linux-next. Which branch in your tree should I be building in order to catch problems like this, perf/core ? https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/core cheers
Em Thu, Apr 14, 2016 at 10:55:47PM +1000, Michael Ellerman escreveu:
> On Thu, 2016-04-14 at 09:35 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > Hi all,
> > >
> > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > failed like this:
> > >
> > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop.
> > >
> > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> >
> > I'll check, should've been caught by a cross compiler build for ppc64le
> > I have in place :-\
> >
> > minimal-ubuntu-x-ppc64el: Ok
> >
> > But maybe not, as this requires audit-libs-devel and that is not present
> > on that minimal ubuntu x-compiler setup, sigh :-\
>
> Hi acme,
>
> I have a jenkins which builds perf on ppc64le, but it only builds Linus' tree
> and linux-next.
>
> Which branch in your tree should I be building in order to catch problems like
> this, perf/core ?
>
> https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/core
yes, please, I use two normally, one for devel stuff, perf/core, and
perf/urgent when sending stuff to the current merge window.
I'll continue trying to get a local, more complete, cross compiler
environment, need to look again at how that multiarch stuff is in
debian...
- Arnaldo
Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc64le perf) > failed like this: > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) > > Presumably caused by commit > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") > > I have reverted that commit for today (which fixes my build problem but > may not be overall correct). Right, I'm trying to figure out how to bet fix that, one way would be to do: diff --git a/tools/perf/util/Build b/tools/perf/util/Build index 85a9ab62e23f..7fc4ac304ed6 100644 --- a/tools/perf/util/Build +++ b/tools/perf/util/Build @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" CFLAGS_parse-events.o += -Wno-redundant-decls -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE $(call rule_mkdir) $(call if_changed_dep,cc_o_c) -------------------------------------------- Now trying to figure out how to, just for x86 to add a dep for those files, but a arch specific thing shouldn't be in tools/perf/util/Build anyway... In the end I want this syscalltbl.c thing to know about all arches, to remove the dependency on audit-libs as the way to map syscall ID to name and vice-versa. So I'll need all arches to generate that arch/$(ARCH)/include/generated/asm/syscalls_64.c file, etc. Doing that by copying from the kernel the files where such info is kept and having a diff check as part of the perf build process, so that we can get notified when it drifts while not tying tools/perf/ to anything outside that can end up breaking the tools/ build when changes happen outside. - Arnaldo
Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > > Hi all, > > > > After merging the tip tree, today's linux-next build (powerpc64le perf) > > failed like this: > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) > > > > Presumably caused by commit > > > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") > > > > I have reverted that commit for today (which fixes my build problem but > > may not be overall correct). > > Right, I'm trying to figure out how to bet fix that, one way would be to > do: Jiri, I think this is enough, i.e. I think we make sure, just like the kernel, that the archheaders target in tools/perf/arch/*/Makefile is called before doing all the other build, no? I.e. when we get to build syscalltbl.o the syscalls_64.c file will be built already, limited testing seems to agree with this :-) - Arnaldo > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > index 85a9ab62e23f..7fc4ac304ed6 100644 > --- a/tools/perf/util/Build > +++ b/tools/perf/util/Build > @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" > CFLAGS_parse-events.o += -Wno-redundant-decls > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE > $(call rule_mkdir) > $(call if_changed_dep,cc_o_c) > > > -------------------------------------------- > > Now trying to figure out how to, just for x86 to add a dep for those > files, but a arch specific thing shouldn't be in tools/perf/util/Build > anyway... > > In the end I want this syscalltbl.c thing to know about all arches, > to remove the dependency on audit-libs as the way to map syscall ID to > name and vice-versa. > > So I'll need all arches to generate that > arch/$(ARCH)/include/generated/asm/syscalls_64.c file, etc. Doing that > by copying from the kernel the files where such info is kept and having > a diff check as part of the perf build process, so that we can get > notified when it drifts while not tying tools/perf/ to anything outside > that can end up breaking the tools/ build when changes happen outside. > > - Arnaldo
On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > Hi all,
> > >
> > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > failed like this:
> > >
> > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop.
> > >
> > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > >
> > > Presumably caused by commit
> > >
> > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > >
> > > I have reverted that commit for today (which fixes my build problem but
> > > may not be overall correct).
> >
> > Right, I'm trying to figure out how to bet fix that, one way would be to
> > do:
>
> Jiri, I think this is enough, i.e. I think we make sure, just like the
> kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> called before doing all the other build, no?
>
> I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> built already, limited testing seems to agree with this :-)
>
> - Arnaldo
>
> > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > index 85a9ab62e23f..7fc4ac304ed6 100644
> > --- a/tools/perf/util/Build
> > +++ b/tools/perf/util/Build
> > @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> > CFLAGS_parse-events.o += -Wno-redundant-decls
> >
> > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
yep, having arch specific target in generic Build file is wrong
I'll have ppc64le available later today, I'll check on that
jirka
On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote: > On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > > > > Hi all, > > > > > > > > After merging the tip tree, today's linux-next build (powerpc64le perf) > > > > failed like this: > > > > > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > > > > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) > > > > > > > > Presumably caused by commit > > > > > > > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") > > > > > > > > I have reverted that commit for today (which fixes my build problem but > > > > may not be overall correct). > > > > > > Right, I'm trying to figure out how to bet fix that, one way would be to > > > do: > > > > Jiri, I think this is enough, i.e. I think we make sure, just like the > > kernel, that the archheaders target in tools/perf/arch/*/Makefile is > > called before doing all the other build, no? > > > > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be > > built already, limited testing seems to agree with this :-) > > > > - Arnaldo > > > > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > > > index 85a9ab62e23f..7fc4ac304ed6 100644 > > > --- a/tools/perf/util/Build > > > +++ b/tools/perf/util/Build > > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET > > > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" > > > CFLAGS_parse-events.o += -Wno-redundant-decls > > > > > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE > > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE > > yep, having arch specific target in generic Build file is wrong > I'll have ppc64le available later today, I'll check on that it looks ok, you can also now remove the whole syscalltbl.o override and archheaders needs to be called before the build starts, which is the case right now thanks, jirka --- diff --git a/tools/perf/util/Build b/tools/perf/util/Build index 85a9ab62e23f..90229a88f969 100644 --- a/tools/perf/util/Build +++ b/tools/perf/util/Build @@ -150,10 +150,6 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" CFLAGS_parse-events.o += -Wno-redundant-decls -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE - $(call rule_mkdir) - $(call if_changed_dep,cc_o_c) - $(OUTPUT)util/kallsyms.o: ../lib/symbol/kallsyms.c FORCE $(call rule_mkdir) $(call if_changed_dep,cc_o_c)
Hi all, After merging the tip tree, today's linux-next build (powerpc64le perf) failed like this: builtin-trace.c: In function 'cmd_trace': builtin-trace.c:3112:7: error: variable 'max_stack_user_set' set but not used [-Werror=unused-but-set-variable] bool max_stack_user_set = true; ^ Caused by commit 056149932602 ("perf trace: Make --(min,max}-stack imply "--call-graph dwarf"") I added the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 18 Apr 2016 12:56:48 +1000 Subject: [PATCH] perf: trace: fix build when HAVE_DWARF_UNWIND_SUPPORT is not set Fixes: 056149932602 ("perf trace: Make --(min,max}-stack imply "--call-graph dwarf"") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- tools/perf/builtin-trace.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c index 026ec0c749b0..48dc23a4f405 100644 --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -3109,7 +3109,9 @@ int cmd_trace(int argc, const char **argv, const char *prefix __maybe_unused) "per thread proc mmap processing timeout in ms"), OPT_END() }; +#ifdef HAVE_DWARF_UNWIND_SUPPORT bool max_stack_user_set = true; +#endif bool mmap_pages_user_set = true; const char * const trace_subcommands[] = { "record", NULL }; int err; @@ -3149,7 +3151,9 @@ int cmd_trace(int argc, const char **argv, const char *prefix __maybe_unused) if (trace.max_stack == UINT_MAX) { trace.max_stack = PERF_MAX_STACK_DEPTH; +#ifdef HAVE_DWARF_UNWIND_SUPPORT max_stack_user_set = false; +#endif } #ifdef HAVE_DWARF_UNWIND_SUPPORT -- 2.7.0 -- Cheers, Stephen Rothwell
Em Sun, Apr 17, 2016 at 03:04:05PM +0200, Jiri Olsa escreveu: > On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote: > > On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu: > > > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu: > > > > > Hi all, > > > > > > > > > > After merging the tip tree, today's linux-next build (powerpc64le perf) > > > > > failed like this: > > > > > > > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop. > > > > > > > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.) > > > > > > > > > > Presumably caused by commit > > > > > > > > > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl") > > > > > > > > > > I have reverted that commit for today (which fixes my build problem but > > > > > may not be overall correct). > > > > > > > > Right, I'm trying to figure out how to bet fix that, one way would be to > > > > do: > > > > > > Jiri, I think this is enough, i.e. I think we make sure, just like the > > > kernel, that the archheaders target in tools/perf/arch/*/Makefile is > > > called before doing all the other build, no? > > > > > > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be > > > built already, limited testing seems to agree with this :-) > > > > > > - Arnaldo > > > > > > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > > > > index 85a9ab62e23f..7fc4ac304ed6 100644 > > > > --- a/tools/perf/util/Build > > > > +++ b/tools/perf/util/Build > > > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET > > > > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" > > > > CFLAGS_parse-events.o += -Wno-redundant-decls > > > > > > > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE > > > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE > > > > yep, having arch specific target in generic Build file is wrong > > I'll have ppc64le available later today, I'll check on that > > it looks ok, you can also now remove the whole syscalltbl.o override Ok, so I'll add this and your Tested-by, ok? - Arnaldo > and archheaders needs to be called before the build starts, > which is the case right now > > thanks, > jirka > > > --- > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > index 85a9ab62e23f..90229a88f969 100644 > --- a/tools/perf/util/Build > +++ b/tools/perf/util/Build > @@ -150,10 +150,6 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))" > CFLAGS_parse-events.o += -Wno-redundant-decls > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE > - $(call rule_mkdir) > - $(call if_changed_dep,cc_o_c) > - > $(OUTPUT)util/kallsyms.o: ../lib/symbol/kallsyms.c FORCE > $(call rule_mkdir) > $(call if_changed_dep,cc_o_c)
On Mon, Apr 18, 2016 at 10:24:02AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, Apr 17, 2016 at 03:04:05PM +0200, Jiri Olsa escreveu:
> > On Sun, Apr 17, 2016 at 02:12:07PM +0200, Jiri Olsa wrote:
> > > On Fri, Apr 15, 2016 at 06:28:31PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Apr 15, 2016 at 06:15:42PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > Em Thu, Apr 14, 2016 at 12:14:18PM +1000, Stephen Rothwell escreveu:
> > > > > > Hi all,
> > > > > >
> > > > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > > > failed like this:
> > > > > >
> > > > > > make[3]: *** No rule to make target '/home/sfr/next/perf/arch/x86/include/generated/asm/syscalls_64.c', needed by '/home/sfr/next/perf/util/syscalltbl.o'. Stop.
> > > > > >
> > > > > > (I build in /home/sfr/next/next with objects in /home/sfr/next/perf.)
> > > > > >
> > > > > > Presumably caused by commit
> > > > > >
> > > > > > 1b700c997500 ("perf tools: Build syscall table .c header from kernel's syscall_64.tbl")
> > > > > >
> > > > > > I have reverted that commit for today (which fixes my build problem but
> > > > > > may not be overall correct).
> > > > >
> > > > > Right, I'm trying to figure out how to bet fix that, one way would be to
> > > > > do:
> > > >
> > > > Jiri, I think this is enough, i.e. I think we make sure, just like the
> > > > kernel, that the archheaders target in tools/perf/arch/*/Makefile is
> > > > called before doing all the other build, no?
> > > >
> > > > I.e. when we get to build syscalltbl.o the syscalls_64.c file will be
> > > > built already, limited testing seems to agree with this :-)
> > > >
> > > > - Arnaldo
> > > >
> > > > > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > > > > index 85a9ab62e23f..7fc4ac304ed6 100644
> > > > > --- a/tools/perf/util/Build
> > > > > +++ b/tools/perf/util/Build
> > > > > @@ -150,7 +150,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ET
> > > > > CFLAGS_hweight.o += -Wno-unused-parameter -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
> > > > > CFLAGS_parse-events.o += -Wno-redundant-decls
> > > > >
> > > > > -$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c arch/x86/entry/syscalls/syscall_64.tbl $(OUTPUT)arch/x86/include/generated/asm/syscalls_64.c FORCE
> > > > > +$(OUTPUT)util/syscalltbl.o: util/syscalltbl.c FORCE
> > >
> > > yep, having arch specific target in generic Build file is wrong
> > > I'll have ppc64le available later today, I'll check on that
> >
> > it looks ok, you can also now remove the whole syscalltbl.o override
>
> Ok, so I'll add this and your Tested-by, ok?
ook ;-)
jirka
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/list.h:4, from elf.h:23, from builtin-check.c:33: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/string.h:5, from ../lib/str_error_r.c:4: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ cat: /home/sfr/next/x86_64_allmodconfig/tools/objtool/.str_error_r.o.d: No such file or directory Build:17: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/str_error_r.o' failed In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/list.h:4, from elf.h:23, from special.h:22, from special.c:26: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/string.h:5, from ../lib/string.c:18: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/list.h:4, from elf.h:23, from elf.c:30: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0, from /usr/include/asm-generic/int-ll64.h:11, from /usr/include/powerpc64le-linux-gnu/asm/types.h:27, from tools/include/linux/types.h:9, from tools/include/linux/list.h:4, from arch/x86/../../elf.h:23, from arch/x86/decode.c:26: tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ Makefile:42: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o' failed Makefile:60: recipe for target 'objtool' failed I have added this patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 18 Jul 2016 14:58:39 +1000 Subject: [PATCH] tools: Simplify __BITS_PER_LONG define Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- tools/include/asm-generic/bitsperlong.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h index 45eca517efb3..f46853474fd3 100644 --- a/tools/include/asm-generic/bitsperlong.h +++ b/tools/include/asm-generic/bitsperlong.h @@ -10,7 +10,8 @@ #endif #if BITS_PER_LONG != __BITS_PER_LONG -#error Inconsistent word size. Check asm/bitsperlong.h +#undef __BITS_PER_LONG +#define __BITS_PER_LONG BITS_PER_LONG #endif #ifndef BITS_PER_LONG_LONG -- 2.8.1 -- Cheers, Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (x86_64 allnoconfig) failed like this: In file included from arch/x86/kernel/x8664_ksyms_64.c:10:0: arch/x86/include/asm/pgtable.h:38:8: error: unknown type name 'spinlock_t' extern spinlock_t pgd_lock; ^ Probably caused by commit 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h") I added this patch for today (maybe adding the include to arch/x86/include/asm/pgtable.h would be better?): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 18 Jul 2016 18:23:24 +1000 Subject: [PATCH] x86/kernel: include spinlock_types.h for missing spinlock_t Fixes: 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/kernel/x8664_ksyms_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c index f6d30fedcc03..95e49f6e4fc3 100644 --- a/arch/x86/kernel/x8664_ksyms_64.c +++ b/arch/x86/kernel/x8664_ksyms_64.c @@ -2,6 +2,7 @@ All C exports should go in the respective C files. */ #include <linux/export.h> +#include <linux/spinlock_types.h> #include <linux/smp.h> #include <net/checksum.h> -- 2.8.1 -- Cheers, Stephen Rothwell
[linux-next: build failure after merge of the tip tree] On 18/07/2016 (Mon 18:29) Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allnoconfig) > failed like this: > > In file included from arch/x86/kernel/x8664_ksyms_64.c:10:0: > arch/x86/include/asm/pgtable.h:38:8: error: unknown type name 'spinlock_t' > extern spinlock_t pgd_lock; > ^ > > Probably caused by commit > > 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h") Wondering why I didn't see this, when I _thought_ I did the same coverage, I learned an interesting thing. I'd been doing make ARCH=i386 allnoconfig make allnoconfig ...figuring on x86_64 host that I'd need to explicitly choose i386 and that w/o an ARCH specified, I'd get the native arch... Not so. I just end up doing the i386 arch coverage twice. :-( I'll go out on a limb here and guess I'm not the only person to fall into that trap. I'll now be using: make ARCH=i386 allnoconfig make ARCH=x86_64 allnoconfig Thanks Stephen for the fix and for helping find this gap in my tests. If my build coverage moves to Power like yours, I'll still be good. :) Paul. -- > > I added this patch for today (maybe adding the include to > arch/x86/include/asm/pgtable.h would be better?): > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 18 Jul 2016 18:23:24 +1000 > Subject: [PATCH] x86/kernel: include spinlock_types.h for missing spinlock_t > > Fixes: 186f43608a5c ("x86/kernel: Audit and remove any unnecessary uses of module.h") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/kernel/x8664_ksyms_64.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c > index f6d30fedcc03..95e49f6e4fc3 100644 > --- a/arch/x86/kernel/x8664_ksyms_64.c > +++ b/arch/x86/kernel/x8664_ksyms_64.c > @@ -2,6 +2,7 @@ > All C exports should go in the respective C files. */ > > #include <linux/export.h> > +#include <linux/spinlock_types.h> > #include <linux/smp.h> > > #include <net/checksum.h> > -- > 2.8.1 > > -- > Cheers, > Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/cpufreq/cpufreq.c:1324:12: error: conflicting types for 'cpufreq_offline' static int cpufreq_offline(unsigned int cpu) ^ drivers/cpufreq/cpufreq.c:1289:13: note: previous declaration of 'cpufreq_offline' was here static void cpufreq_offline(unsigned int cpu); ^ Caused by commit 27622b061eb4 ("cpufreq: Convert to hotplug state machine") interacting with commit 26619804e733 ("cpufreq: create link to policy only for registered CPUs") from the pm tree. I have applied the foloowing build fix for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 21 Sep 2016 13:20:32 +1000 Subject: [PATCH] cpufreq: merge fix for type of cpufreq_offline changing Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 611395cb115e..6e6c1fb60fbc 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1286,7 +1286,7 @@ out_free_policy: return ret; } -static void cpufreq_offline(unsigned int cpu); +static int cpufreq_offline(unsigned int cpu); /** * cpufreq_add_dev - the cpufreq interface for a CPU device. -- 2.8.1 -- Cheers, Stephen Rothwell
On 21-09-16, 13:23, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/cpufreq/cpufreq.c:1324:12: error: conflicting types for 'cpufreq_offline'
> static int cpufreq_offline(unsigned int cpu)
> ^
> drivers/cpufreq/cpufreq.c:1289:13: note: previous declaration of 'cpufreq_offline' was here
> static void cpufreq_offline(unsigned int cpu);
> ^
>
> Caused by commit
>
> 27622b061eb4 ("cpufreq: Convert to hotplug state machine")
>
> interacting with commit
>
> 26619804e733 ("cpufreq: create link to policy only for registered CPUs")
>
> from the pm tree.
>
> I have applied the foloowing build fix for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 21 Sep 2016 13:20:32 +1000
> Subject: [PATCH] cpufreq: merge fix for type of cpufreq_offline changing
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/cpufreq/cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 611395cb115e..6e6c1fb60fbc 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1286,7 +1286,7 @@ out_free_policy:
> return ret;
> }
>
> -static void cpufreq_offline(unsigned int cpu);
> +static int cpufreq_offline(unsigned int cpu);
Thanks and sorry about it. Looks fine.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save': arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types] get_e820_md5(&e820_saved, buf); ^ arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **' static int get_e820_md5(struct e820map *map, void *buf) ^ arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch': arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types] ret = get_e820_md5(&e820_saved, result); ^ arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **' static int get_e820_md5(struct e820map *map, void *buf) ^ Caused by commit 475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic storage") interacting with commit 6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5 digest") from the pm tree. I have applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 29 Sep 2016 13:13:45 +1000 Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved changing Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/power/hibernate_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c index 72f2c9531b03..904048f7a9c9 100644 --- a/arch/x86/power/hibernate_64.c +++ b/arch/x86/power/hibernate_64.c @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void *buf) static void hibernation_e820_save(void *buf) { - get_e820_md5(&e820_saved, buf); + get_e820_md5(e820_saved, buf); } static bool hibernation_e820_mismatch(void *buf) @@ -246,7 +246,7 @@ static bool hibernation_e820_mismatch(void *buf) if (!memcmp(result, buf, MD5_DIGEST_SIZE)) return false; - ret = get_e820_md5(&e820_saved, result); + ret = get_e820_md5(e820_saved, result); if (ret) return true; -- 2.8.1 -- Cheers, Stephen Rothwell
On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
> get_e820_md5(&e820_saved, buf);
> ^
> arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
> static int get_e820_md5(struct e820map *map, void *buf)
> ^
> arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-pointer-types]
> ret = get_e820_md5(&e820_saved, result);
> ^
> arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *' but argument is of type 'struct e820map **'
> static int get_e820_md5(struct e820map *map, void *buf)
> ^
>
> Caused by commit
>
> 475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic storage")
>
> interacting with commit
>
> 6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5 digest")
>
> from the pm tree.
>
> I have applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Sep 2016 13:13:45 +1000
> Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved changing
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/x86/power/hibernate_64.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
> index 72f2c9531b03..904048f7a9c9 100644
> --- a/arch/x86/power/hibernate_64.c
> +++ b/arch/x86/power/hibernate_64.c
> @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void *buf)
>
> static void hibernation_e820_save(void *buf)
> {
> - get_e820_md5(&e820_saved, buf);
> + get_e820_md5(e820_saved, buf);
> }
>
> static bool hibernation_e820_mismatch(void *buf)
> @@ -246,7 +246,7 @@ static bool hibernation_e820_mismatch(void *buf)
> if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> return false;
>
> - ret = get_e820_md5(&e820_saved, result);
> + ret = get_e820_md5(e820_saved, result);
> if (ret)
> return true;
>
>
Looks good to me, thanks Stephen!
Rafael
Hi,
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Thursday, September 29, 2016 8:25 PM
> To: Stephen Rothwell
> Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org; Denys Vlasenko; Chen, Yu
> C
> Subject: Re: linux-next: build failure after merge of the tip tree
>
> On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> > arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of
> 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> pointer-types]
> > get_e820_md5(&e820_saved, buf);
> > ^
> > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> but argument is of type 'struct e820map **'
> > static int get_e820_md5(struct e820map *map, void *buf)
> > ^
> > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> > arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of
> 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> pointer-types]
> > ret = get_e820_md5(&e820_saved, result);
> > ^
> > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> but argument is of type 'struct e820map **'
> > static int get_e820_md5(struct e820map *map, void *buf)
> > ^
> >
> > Caused by commit
> >
> > 475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic
> > storage")
> >
> > interacting with commit
> >
> > 6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5
> > digest")
> >
> > from the pm tree.
> >
> > I have applied the following merge fix patch:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 29 Sep 2016 13:13:45 +1000
> > Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved
> > changing
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > arch/x86/power/hibernate_64.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/power/hibernate_64.c
> > b/arch/x86/power/hibernate_64.c index 72f2c9531b03..904048f7a9c9
> > 100644
> > --- a/arch/x86/power/hibernate_64.c
> > +++ b/arch/x86/power/hibernate_64.c
> > @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void
> > *buf)
> >
> > static void hibernation_e820_save(void *buf) {
> > - get_e820_md5(&e820_saved, buf);
> > + get_e820_md5(e820_saved, buf);
> > }
> >
> > static bool hibernation_e820_mismatch(void *buf) @@ -246,7 +246,7 @@
> > static bool hibernation_e820_mismatch(void *buf)
> > if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> > return false;
> >
> > - ret = get_e820_md5(&e820_saved, result);
> > + ret = get_e820_md5(e820_saved, result);
> > if (ret)
> > return true;
> >
> >
>
> Looks good to me, thanks Stephen!
>
> Rafael
Thanks for the fix!
I made a double check of the patch :
"x86/e820: Prepare e280 code for switch to dynamic storage"
It looks like this patch has reallocate the e820 & e820_save to their actual size:
+ size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820->nr_map;
+ n = kmalloc(size, GFP_KERNEL);
however the previous patch to verify the md5 hash during hibernation will
use the original e820_map structure by sizeof(struct e820map), which might
read invalid value after the latest patch applied. I think I need to modify the
hibernation e820 checking patch to only generate md5 digest based on the actual
e820_save size by sizeof(struct e820entry) * e820->nr_map.
I don't have a machine in hand now, will test later and give feedback later. Thanks again!
Yu
On Thursday, September 29, 2016 03:54:24 PM Chen, Yu C wrote:
> Hi,
>
> > -----Original Message-----
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Sent: Thursday, September 29, 2016 8:25 PM
> > To: Stephen Rothwell
> > Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; linux-
> > next@vger.kernel.org; linux-kernel@vger.kernel.org; Denys Vlasenko; Chen, Yu
> > C
> > Subject: Re: linux-next: build failure after merge of the tip tree
> >
> > On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the tip tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save':
> > > arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of
> > 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> > pointer-types]
> > > get_e820_md5(&e820_saved, buf);
> > > ^
> > > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> > but argument is of type 'struct e820map **'
> > > static int get_e820_md5(struct e820map *map, void *buf)
> > > ^
> > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_mismatch':
> > > arch/x86/power/hibernate_64.c:249:21: error: passing argument 1 of
> > 'get_e820_md5' from incompatible pointer type [-Werror=incompatible-
> > pointer-types]
> > > ret = get_e820_md5(&e820_saved, result);
> > > ^
> > > arch/x86/power/hibernate_64.c:203:12: note: expected 'struct e820map *'
> > but argument is of type 'struct e820map **'
> > > static int get_e820_md5(struct e820map *map, void *buf)
> > > ^
> > >
> > > Caused by commit
> > >
> > > 475339684ef1 ("x86/e820: Prepare e280 code for switch to dynamic
> > > storage")
> > >
> > > interacting with commit
> > >
> > > 6f95ad2b6162 ("PM / hibernate: Verify e820 memory map by MD5
> > > digest")
> > >
> > > from the pm tree.
> > >
> > > I have applied the following merge fix patch:
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 29 Sep 2016 13:13:45 +1000
> > > Subject: [PATCH] pm/hibernate: merge fix for type of e820_saved
> > > changing
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > arch/x86/power/hibernate_64.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/power/hibernate_64.c
> > > b/arch/x86/power/hibernate_64.c index 72f2c9531b03..904048f7a9c9
> > > 100644
> > > --- a/arch/x86/power/hibernate_64.c
> > > +++ b/arch/x86/power/hibernate_64.c
> > > @@ -233,7 +233,7 @@ static int get_e820_md5(struct e820map *map, void
> > > *buf)
> > >
> > > static void hibernation_e820_save(void *buf) {
> > > - get_e820_md5(&e820_saved, buf);
> > > + get_e820_md5(e820_saved, buf);
> > > }
> > >
> > > static bool hibernation_e820_mismatch(void *buf) @@ -246,7 +246,7 @@
> > > static bool hibernation_e820_mismatch(void *buf)
> > > if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> > > return false;
> > >
> > > - ret = get_e820_md5(&e820_saved, result);
> > > + ret = get_e820_md5(e820_saved, result);
> > > if (ret)
> > > return true;
> > >
> > >
> >
> > Looks good to me, thanks Stephen!
> >
> > Rafael
> Thanks for the fix!
>
> I made a double check of the patch :
> "x86/e820: Prepare e280 code for switch to dynamic storage"
> It looks like this patch has reallocate the e820 & e820_save to their actual size:
> + size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820->nr_map;
> + n = kmalloc(size, GFP_KERNEL);
>
> however the previous patch to verify the md5 hash during hibernation will
> use the original e820_map structure by sizeof(struct e820map), which might
> read invalid value after the latest patch applied. I think I need to modify the
> hibernation e820 checking patch to only generate md5 digest based on the actual
> e820_save size by sizeof(struct e820entry) * e820->nr_map.
>
> I don't have a machine in hand now, will test later and give feedback later. Thanks again!
OK, dropping the hibernation patch for now.
I'll wait for an update on top of 4.9-rc1.
Thanks,
Rafael
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/core/dev.c: In function 'sk_busy_loop': net/core/dev.c:5065:3: error: implicit declaration of function 'cpu_relax_lowlatency' [-Werror=implicit-function-declaration] cpu_relax_lowlatency(); ^ Caused by commit 5bd0b85ba8bb ("locking/core, arch: Remove cpu_relax_lowlatency()") interacting with commit 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()") from the net-next tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 17 Nov 2016 14:13:05 +1100 Subject: [PATCH] net: busy-poll: fix up for cpu_relax_lowlatency() removal Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index d29d538ec5ad..6b9f8eb55b62 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -5062,7 +5062,7 @@ bool sk_busy_loop(struct sock *sk, int nonblock) return rc; goto restart; } - cpu_relax_lowlatency(); + cpu_relax(); } if (napi_poll) busy_poll_stop(napi, have_poll_lock); -- 2.10.2 -- Cheers, Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (powerpc64le perf) failed like this: LINK /home/sfr/next/perf/fixdep /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed $ ls -l /home/sfr/next/perf/fixdep -rwxr-xr-x 1 sfr users 71104 Dec 7 12:26 /home/sfr/next/perf/fixdep I am not sure what caused this, but redoing the build succeeded, so I have just filed this report and left it for today. -- Cheers, Stephen Rothwell
Cc:-ing Arnaldo, Jiri, Wang Nan and Peter Foley - bug report quoted below.
This bug/race might have been introduced in the latest tooling bits:
34c4a42791bb Merge tag 'perf-core-for-mingo-20161205' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Which included these build system changes:
triton:~/tip> gll 78987584de42..perf/core
34c4a42791bb Merge tag 'perf-core-for-mingo-20161205' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
bec60e50af83 perf annotate: Show raw form for jump instruction with indirect target
d4dcadec43de perf tools: Add non config targets
207da4739e3e perf tools: Cleanup build directory before each test
0b4d4b076251 perf tools: Move python/perf.so target into rules area
5c319a67b13d perf tools: Move install-gtk target into rules area
2fedf79b69cf tools build: Move tabs to spaces where suitable
a5ba0a1a5af3 tools build: Make the .cmd file more readable
edd695b032ba perf clang: Compile BPF script using builtin clang support
5e08a76525b8 perf clang: Support compile IR to BPF object and add testcase
e67d52d411c3 perf clang: Update test case to use real BPF script
a9495fe9dc63 perf clang: Allow passing CFLAGS to builtin clang
77dfa84a843c perf clang: Use real file system for #include
00b86691c77c perf clang: Add builtin clang support ant test case
d58ac0bf8d1e perf build: Add clang and llvm compile and linking support
c7fb4f62e2a9 tools build: Add feature detection for clang
cb40d55b595c tools build: Add feature detection for LLVM
2bd42de0e196 perf llvm: Extract helpers in llvm-utils.c
8ad85e9e6fda perf tools: Pass context to perf hook functions
baa1973ebcf6 tools build: Fix objtool build with clang
1cd6472e3f8d tools build: Make fixdep parsing wait for last target
Thanks,
Ingo
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> failed like this:
>
> LINK /home/sfr/next/perf/fixdep
> /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
>
> $ ls -l /home/sfr/next/perf/fixdep
> -rwxr-xr-x 1 sfr users 71104 Dec 7 12:26 /home/sfr/next/perf/fixdep
>
> I am not sure what caused this, but redoing the build succeeded, so I
> have just filed this report and left it for today.
On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote:
SNIP
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > failed like this:
> >
> > LINK /home/sfr/next/perf/fixdep
> > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> >
> > $ ls -l /home/sfr/next/perf/fixdep
> > -rwxr-xr-x 1 sfr users 71104 Dec 7 12:26 /home/sfr/next/perf/fixdep
> >
> > I am not sure what caused this, but redoing the build succeeded, so I
> > have just filed this report and left it for today.
this seems to be the rare race issue caused by missing fixdep dependency,
caused probably by recompiling of fixdep because of its change in the merge
Arnaldo already carries a fix for this in his latest perf/core, where
we moved the fixdep compilation on top of everything to kill any future
race due to missing fixdep dependency
thanks,
jirka
Em Wed, Dec 07, 2016 at 09:12:15AM +0100, Jiri Olsa escreveu: > On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote: > > SNIP > > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > Hi all, > > > > > > After merging the tip tree, today's linux-next build (powerpc64le perf) > > > failed like this: > > > > > > LINK /home/sfr/next/perf/fixdep > > > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied > > > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed > > > > > > $ ls -l /home/sfr/next/perf/fixdep > > > -rwxr-xr-x 1 sfr users 71104 Dec 7 12:26 /home/sfr/next/perf/fixdep > > > > > > I am not sure what caused this, but redoing the build succeeded, so I > > > have just filed this report and left it for today. > > this seems to be the rare race issue caused by missing fixdep dependency, > caused probably by recompiling of fixdep because of its change in the merge > > Arnaldo already carries a fix for this in his latest perf/core, where > we moved the fixdep compilation on top of everything to kill any future > race due to missing fixdep dependency I'll push it today, will stop processing other stuff now and prepare a pull request, - Arnaldo > thanks, > jirka
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Wed, Dec 07, 2016 at 09:12:15AM +0100, Jiri Olsa escreveu:
> > On Wed, Dec 07, 2016 at 08:45:14AM +0100, Ingo Molnar wrote:
> >
> > SNIP
> >
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > > Hi all,
> > > >
> > > > After merging the tip tree, today's linux-next build (powerpc64le perf)
> > > > failed like this:
> > > >
> > > > LINK /home/sfr/next/perf/fixdep
> > > > /bin/sh: 1: /home/sfr/next/perf//fixdep: Permission denied
> > > > tools/build/Makefile.build:91: recipe for target '/home/sfr/next/perf/pmu-events/jevents.o' failed
> > > >
> > > > $ ls -l /home/sfr/next/perf/fixdep
> > > > -rwxr-xr-x 1 sfr users 71104 Dec 7 12:26 /home/sfr/next/perf/fixdep
> > > >
> > > > I am not sure what caused this, but redoing the build succeeded, so I
> > > > have just filed this report and left it for today.
> >
> > this seems to be the rare race issue caused by missing fixdep dependency,
> > caused probably by recompiling of fixdep because of its change in the merge
> >
> > Arnaldo already carries a fix for this in his latest perf/core, where
> > we moved the fixdep compilation on top of everything to kill any future
> > race due to missing fixdep dependency
>
> I'll push it today, will stop processing other stuff now and prepare a
> pull request,
Thanks - I pushed the fixes towards linux-next, so tomorrow's (today's) linux-next
build should not trigger this build race.
Thanks,
Ingo
Hi all,
On Wed, 7 Dec 2016 19:56:32 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> > I'll push it today, will stop processing other stuff now and prepare a
> > pull request,
>
> Thanks - I pushed the fixes towards linux-next, so tomorrow's (today's) linux-next
> build should not trigger this build race.
Thanks for the quick response.
--
Cheers,
Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/gpu/built-in.o:(__tracepoints+0x64): multiple definition of `__tracepoint_remove_device_from_group' drivers/iommu/built-in.o:(__tracepoints+0x64): first defined here drivers/gpu/built-in.o:(__tracepoints+0x3c): multiple definition of `__tracepoint_detach_device_from_domain' drivers/iommu/built-in.o:(__tracepoints+0x3c): first defined here drivers/gpu/built-in.o:(__tracepoints+0x0): multiple definition of `__tracepoint_io_page_fault' drivers/iommu/built-in.o:(__tracepoints+0x0): first defined here drivers/gpu/built-in.o:(__tracepoints+0x78): multiple definition of `__tracepoint_add_device_to_group' drivers/iommu/built-in.o:(__tracepoints+0x78): first defined here drivers/gpu/built-in.o:(__tracepoints+0x14): multiple definition of `__tracepoint_unmap' drivers/iommu/built-in.o:(__tracepoints+0x14): first defined here drivers/gpu/built-in.o:(__tracepoints+0x28): multiple definition of `__tracepoint_map' drivers/iommu/built-in.o:(__tracepoints+0x28): first defined here drivers/gpu/built-in.o:(__tracepoints+0x50): multiple definition of `__tracepoint_attach_device_to_domain' drivers/iommu/built-in.o:(__tracepoints+0x50): first defined here The tip tree has not changed since yesterday. However, reverting the drm-tegra tree fixes the build problem. So there is some interaction between the tip tree and today's drm-tegra tree. So for now, I have reverted the merge of the drm-tegra tree. -- Cheers, Stephen Rothwell
On 05.04.2017 06:36, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/built-in.o:(__tracepoints+0x64): multiple definition of `__tracepoint_remove_device_from_group'
> drivers/iommu/built-in.o:(__tracepoints+0x64): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x3c): multiple definition of `__tracepoint_detach_device_from_domain'
> drivers/iommu/built-in.o:(__tracepoints+0x3c): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x0): multiple definition of `__tracepoint_io_page_fault'
> drivers/iommu/built-in.o:(__tracepoints+0x0): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x78): multiple definition of `__tracepoint_add_device_to_group'
> drivers/iommu/built-in.o:(__tracepoints+0x78): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x14): multiple definition of `__tracepoint_unmap'
> drivers/iommu/built-in.o:(__tracepoints+0x14): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x28): multiple definition of `__tracepoint_map'
> drivers/iommu/built-in.o:(__tracepoints+0x28): first defined here
> drivers/gpu/built-in.o:(__tracepoints+0x50): multiple definition of `__tracepoint_attach_device_to_domain'
> drivers/iommu/built-in.o:(__tracepoints+0x50): first defined here
>
> The tip tree has not changed since yesterday. However, reverting
> the drm-tegra tree fixes the build problem. So there is some interaction
> between the tip tree and today's drm-tegra tree.
>
> So for now, I have reverted the merge of the drm-tegra tree.
>
Looks like this is caused by my patch to add IOMMU support to Host1x.
I'm confused by how it doesn't appear on ARMv8, though. The cause is
that host1x/dev.c defines CREATE_TRACE_POINTS and includes
trace/events/host1x.h, which is fine. However, it then also includes,
among other local files, dev.h. This used to be fine, but my patch adds
an include of linux/iommu.h to dev.h, so we get this failure. I'll post
a fix shortly.
Thanks,
Mikko.
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: kernel/tracepoint.c: In function 'tracepoint_remove_func': kernel/tracepoint.c:253:4: error: implicit declaration of function 'static_key_slow_dec_cpuslocked' [-Werror=implicit-function-declaration] static_key_slow_dec_cpuslocked(&tp->key); ^ Caused by commit 24db7a671bd5 ("trace/perf: Cure hotplug lock ordering issues") static_key_slow_dec_cpuslocked() is only defined if HAVE_JUMP_LABEL is set - which is only defined if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL). CONFIG_JUMP_LABEL is not set for this build. I wasn't sure if just adding #define static_key_slow_dec_cpuslocked static_key_slow_dec in the !HAVE_JUMP_LABEL case in include/linux/jump_label.h would be sufficient, so I have reverted that commit for today. -- Cheers, Stephen Rothwell
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/tracepoint.c: In function 'tracepoint_remove_func':
> kernel/tracepoint.c:253:4: error: implicit declaration of function 'static_key_slow_dec_cpuslocked' [-Werror=implicit-function-declaration]
> static_key_slow_dec_cpuslocked(&tp->key);
> ^
>
> Caused by commit
>
> 24db7a671bd5 ("trace/perf: Cure hotplug lock ordering issues")
>
> static_key_slow_dec_cpuslocked() is only defined if HAVE_JUMP_LABEL is
> set - which is only defined if defined(CC_HAVE_ASM_GOTO) &&
> defined(CONFIG_JUMP_LABEL). CONFIG_JUMP_LABEL is not set for this build.
>
> I wasn't sure if just adding
>
> #define static_key_slow_dec_cpuslocked static_key_slow_dec
>
> in the !HAVE_JUMP_LABEL case in include/linux/jump_label.h would be
> sufficient, so I have reverted that commit for today.
Both are fine, thanks Stephen! It's all fixed up in tip:auto-latest as well.
Thanks,
Ingo
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/nvdimm/pmem.c: In function 'pmem_freeze_queue': drivers/nvdimm/pmem.c:237:2: error: implicit declaration of function 'blk_mq_freeze_queue_start' [-Werror=implicit-function-declaration] blk_mq_freeze_queue_start(q); ^ Caused by commit 71389703839e ("mm, zone_device: Replace {get, put}_zone_device_page() with a single reference to fix pmem crash") interacting with commit 1671d522cdd9 ("block: rename blk_mq_freeze_queue_start()") from Linus' tree. I have applied the merge fix patch below. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 2 May 2017 13:09:41 +1000 Subject: [PATCH] mm, zone_device: merge fix up for blk_mq_freeze_queue_start() rename Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/nvdimm/pmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index fb7bbc79ac26..fbc640bf06b0 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -234,7 +234,7 @@ static void pmem_release_queue(void *q) static void pmem_freeze_queue(void *q) { - blk_mq_freeze_queue_start(q); + blk_freeze_queue_start(q); } static void pmem_release_disk(void *disk) -- 2.11.0 -- Cheers, Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t' static int hidp_session_wake_function(wait_queue_t *wait, ^ In file included from include/linux/mmzone.h:9:0, from include/linux/gfp.h:5, from include/linux/kmod.h:22, from include/linux/module.h:13, from net/bluetooth/hidp/core.c:25: net/bluetooth/hidp/core.c: In function 'hidp_session_thread': net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function) DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function); ^ include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC' .func = function, \ ^ net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function); ^ include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC' .func = function, \ ^ Caused by commit ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t") interacting with commit 5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread") from the bluetooth tree. I should have fixed this up in the merge, sorry. I added the following merge fix for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 28 Jun 2017 13:36:04 +1000 Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t => wait_queue_entry_t" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/bluetooth/hidp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c index 472b3907b1b0..002743ea509c 100644 --- a/net/bluetooth/hidp/core.c +++ b/net/bluetooth/hidp/core.c @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session) smp_mb__after_atomic(); } -static int hidp_session_wake_function(wait_queue_t *wait, +static int hidp_session_wake_function(wait_queue_entry_t *wait, unsigned int mode, int sync, void *key) { -- 2.11.0 -- Cheers, Stephen Rothwell
Hi Stephen, On 06/28/2017 11:43 AM, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t' > static int hidp_session_wake_function(wait_queue_t *wait, > ^ > In file included from include/linux/mmzone.h:9:0, > from include/linux/gfp.h:5, > from include/linux/kmod.h:22, > from include/linux/module.h:13, > from net/bluetooth/hidp/core.c:25: > net/bluetooth/hidp/core.c: In function 'hidp_session_thread': > net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function) > DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function); > ^ > include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC' > .func = function, \ > ^ > net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in > DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function); > ^ > include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC' > .func = function, \ > ^ > > Caused by commit > > ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t") > > interacting with commit > > 5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread") > > from the bluetooth tree. I should have fixed this up in the merge, sorry. > I added the following merge fix for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Wed, 28 Jun 2017 13:36:04 +1000 > Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t => > wait_queue_entry_t" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > net/bluetooth/hidp/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c > index 472b3907b1b0..002743ea509c 100644 > --- a/net/bluetooth/hidp/core.c > +++ b/net/bluetooth/hidp/core.c > @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session) > smp_mb__after_atomic(); > } > > -static int hidp_session_wake_function(wait_queue_t *wait, > +static int hidp_session_wake_function(wait_queue_entry_t *wait, thanx for fixing this. and i saw commit 50816c48997af857d4bab3dca1aba90339705e96 Author: Ingo Molnar <mingo@kernel.org> Date: Sun Mar 5 10:33:16 2017 +0100 sched/wait: Standardize internal naming of wait-queue entries changed wait_queue_entry_t to struct wait_queue_entry, and also wait to wq_entry, maybe we should do it too? > unsigned int mode, > int sync, void *key) > { >
Hi jeffy,
On Wed, 28 Jun 2017 12:00:19 +0800 jeffy <jeffy.chen@rock-chips.com> wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar <mingo@kernel.org>
> Date: Sun Mar 5 10:33:16 2017 +0100
>
> sched/wait: Standardize internal naming of wait-queue entries
>
>
> changed wait_queue_entry_t to struct wait_queue_entry, and also wait to
> wq_entry, maybe we should do it too?
Sure, but that can be done later.
--
Cheers,
Stephen Rothwell
Hi all,
With the merge window opening, just a reminder that this semantic
conflict still exists.
On Wed, 28 Jun 2017 13:43:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
> static int hidp_session_wake_function(wait_queue_t *wait,
> ^
> In file included from include/linux/mmzone.h:9:0,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from net/bluetooth/hidp/core.c:25:
> net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
> net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' undeclared (first use in this function)
> DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
> ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
> .func = function, \
> ^
> net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is reported only once for each function it appears in
> DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
> ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
> .func = function, \
> ^
>
> Caused by commit
>
> ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
>
> interacting with commit
>
> 5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in hidp_session_thread")
>
> from the bluetooth tree. I should have fixed this up in the merge, sorry.
> I added the following merge fix for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Jun 2017 13:36:04 +1000
> Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
> wait_queue_entry_t"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/bluetooth/hidp/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 472b3907b1b0..002743ea509c 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session *session)
> smp_mb__after_atomic();
> }
>
> -static int hidp_session_wake_function(wait_queue_t *wait,
> +static int hidp_session_wake_function(wait_queue_entry_t *wait,
> unsigned int mode,
> int sync, void *key)
> {
> --
> 2.11.0
>
> --
> Cheers,
> Stephen Rothwell
--
Cheers,
Stephen Rothwell
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/workqueue.h:8:0, from include/linux/srcu.h:34, from include/linux/notifier.h:15, from include/linux/memory_hotplug.h:6, from include/linux/mmzone.h:779, from include/linux/gfp.h:5, from include/linux/umh.h:4, from include/linux/kmod.h:22, from include/linux/module.h:13, from drivers/net/ethernet/chelsio/cxgb/common.h:43, from drivers/net/ethernet/chelsio/cxgb/sge.c:39: drivers/net/ethernet/chelsio/cxgb/sge.c: In function 't1_sge_create': include/linux/timer.h:176:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] __setup_timer(timer, (TIMER_FUNC_TYPE)callback, \ ^ include/linux/timer.h:122:25: note: in definition of macro '__setup_timer' (_timer)->function = (_fn); \ ^ drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' timer_setup(&sge->espibug_timer, ^ drivers/net/ethernet/chelsio/cxgb/sge.c:2082:31: warning: comparison between pointer and integer adapter->params.nports > 1 ? espibug_workaround_t204 : espibug_workaround, ^ include/linux/timer.h:122:25: note: in definition of macro '__setup_timer' (_timer)->function = (_fn); \ ^ drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' timer_setup(&sge->espibug_timer, ^ include/linux/timer.h:122:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] (_timer)->function = (_fn); \ ^ include/linux/timer.h:176:3: note: in expansion of macro '__setup_timer' __setup_timer(timer, (TIMER_FUNC_TYPE)callback, \ ^ drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' timer_setup(&sge->espibug_timer, ^ and another similar. Caused by commit cacd2b3fb981 ("chelsio: Convert timers to use timer_setup()") from te net-next tree interacting with commit 52f737c2da40 ("timer: Provide wrappers safe for use with LOCKDEP") from the tip tree. Looks like the LOCKDEP sage version of timer_setup() needs to put parentheses around the usages of its parameters? -- Cheers, Stephen Rothwell
On Wed, Nov 1, 2017 at 3:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from include/linux/workqueue.h:8:0, > from include/linux/srcu.h:34, > from include/linux/notifier.h:15, > from include/linux/memory_hotplug.h:6, > from include/linux/mmzone.h:779, > from include/linux/gfp.h:5, > from include/linux/umh.h:4, > from include/linux/kmod.h:22, > from include/linux/module.h:13, > from drivers/net/ethernet/chelsio/cxgb/common.h:43, > from drivers/net/ethernet/chelsio/cxgb/sge.c:39: > drivers/net/ethernet/chelsio/cxgb/sge.c: In function 't1_sge_create': > include/linux/timer.h:176:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > __setup_timer(timer, (TIMER_FUNC_TYPE)callback, \ > ^ > include/linux/timer.h:122:25: note: in definition of macro '__setup_timer' > (_timer)->function = (_fn); \ > ^ > drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' > timer_setup(&sge->espibug_timer, > ^ > drivers/net/ethernet/chelsio/cxgb/sge.c:2082:31: warning: comparison between pointer and integer > adapter->params.nports > 1 ? espibug_workaround_t204 : espibug_workaround, > ^ > include/linux/timer.h:122:25: note: in definition of macro '__setup_timer' > (_timer)->function = (_fn); \ > ^ > drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' > timer_setup(&sge->espibug_timer, > ^ > include/linux/timer.h:122:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] > (_timer)->function = (_fn); \ > ^ > include/linux/timer.h:176:3: note: in expansion of macro '__setup_timer' > __setup_timer(timer, (TIMER_FUNC_TYPE)callback, \ > ^ > drivers/net/ethernet/chelsio/cxgb/sge.c:2081:3: note: in expansion of macro 'timer_setup' > timer_setup(&sge->espibug_timer, > ^ > > and another similar. > > Caused by commit > > cacd2b3fb981 ("chelsio: Convert timers to use timer_setup()") > > from te net-next tree interacting with commit > > 52f737c2da40 ("timer: Provide wrappers safe for use with LOCKDEP") > > from the tip tree. > > Looks like the LOCKDEP sage version of timer_setup() needs to put > parentheses around the usages of its parameters? Ugh, yup. Thanks for the catch. I have no idea why I didn't see this in my own builds. -Kees > > -- > Cheers, > Stephen Rothwell > -- > To unsubscribe from this list: send the line "unsubscribe linux-next" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Kees Cook Pixel Security
Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from orc_dump.c:19:0: orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory #include <asm/orc_types.h> ^~~~~~~~~~~~~~~~~ compilation terminated. mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.orc_dump.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/orc_dump.o' failed In file included from orc_gen.c:21:0: orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory #include <asm/orc_types.h> ^~~~~~~~~~~~~~~~~ compilation terminated. mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.orc_gen.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/orc_gen.o' failed In file included from check.h:25:0, from builtin-check.c:30: orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory #include <asm/orc_types.h> ^~~~~~~~~~~~~~~~~ compilation terminated. In file included from check.h:25:0, from builtin-orc.c:30: orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory #include <asm/orc_types.h> ^~~~~~~~~~~~~~~~~ compilation terminated. mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.builtin-check.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o' failed mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.builtin-orc.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-orc.o' failed In file included from check.h:25:0, from check.c:21: orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory #include <asm/orc_types.h> ^~~~~~~~~~~~~~~~~ compilation terminated. mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/.check.o.tmp': No such file or directory tools/build/Makefile.build:96: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/check.o' failed arch/x86/decode.c:22:10: fatal error: asm/insn.h: No such file or directory #include <asm/insn.h> ^~~~~~~~~~~~ compilation terminated. mv: cannot stat '/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/.decode.o.tmp': No such file or directory Presumably caused by commit 6a77cff819ae ("objtool: Move synced files to their original relative locations") If it matters, this is a cross compilation (PowerPC host) using O= . I have used the tip tree from next-20171107 for today. -- Cheers, Stephen Rothwell
On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote: > Presumably caused by commit > > 6a77cff819ae ("objtool: Move synced files to their original relative locations") > > If it matters, this is a cross compilation (PowerPC host) using O= . > > I have used the tip tree from next-20171107 for today. Hi Stephen, Does this fix it? diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 6aaed251b4ed..0f94af3ccaaa 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -27,7 +27,7 @@ all: $(OBJTOOL) INCLUDES := -I$(srctree)/tools/include \ -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \ - -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include + -I$(srctree)/tools/objtool/arch/$(ARCH)/include WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES) LDFLAGS += -lelf $(LIBSUBCMD)
Hi Josh,
On Tue, 7 Nov 2017 21:01:52 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > Presumably caused by commit
> >
> > 6a77cff819ae ("objtool: Move synced files to their original relative locations")
> >
> > If it matters, this is a cross compilation (PowerPC host) using O= .
> >
> > I have used the tip tree from next-20171107 for today.
>
> Hi Stephen,
>
> Does this fix it?
>
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 6aaed251b4ed..0f94af3ccaaa 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -27,7 +27,7 @@ all: $(OBJTOOL)
>
> INCLUDES := -I$(srctree)/tools/include \
> -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> - -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> + -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> LDFLAGS += -lelf $(LIBSUBCMD)
Yes, thanks.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell
* Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > Presumably caused by commit
> >
> > 6a77cff819ae ("objtool: Move synced files to their original relative locations")
> >
> > If it matters, this is a cross compilation (PowerPC host) using O= .
> >
> > I have used the tip tree from next-20171107 for today.
>
> Hi Stephen,
>
> Does this fix it?
>
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 6aaed251b4ed..0f94af3ccaaa 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -27,7 +27,7 @@ all: $(OBJTOOL)
>
> INCLUDES := -I$(srctree)/tools/include \
> -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> - -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> + -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> LDFLAGS += -lelf $(LIBSUBCMD)
Note, I created a commit out of this fix, with your SOB - let me know if you have
any objections.
Thanks,
Ingo
Hi Ingo,
On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> Note, I created a commit out of this fix, with your SOB - let me know if you have
> any objections.
Only a small nit - I didn't bisect it, I just figured it out by
inspection. Unfortunately, I don't have time to do bisections while
building linux-next. :-(
Not a biggie, though. Thanks for sorting this out.
--
Cheers,
Stephen Rothwell
On Wed, Nov 08, 2017 at 10:18:28AM +0100, Ingo Molnar wrote:
>
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> > > Presumably caused by commit
> > >
> > > 6a77cff819ae ("objtool: Move synced files to their original relative locations")
> > >
> > > If it matters, this is a cross compilation (PowerPC host) using O= .
> > >
> > > I have used the tip tree from next-20171107 for today.
> >
> > Hi Stephen,
> >
> > Does this fix it?
> >
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 6aaed251b4ed..0f94af3ccaaa 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -27,7 +27,7 @@ all: $(OBJTOOL)
> >
> > INCLUDES := -I$(srctree)/tools/include \
> > -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> > - -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> > + -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> > WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> > CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> > LDFLAGS += -lelf $(LIBSUBCMD)
>
> Note, I created a commit out of this fix, with your SOB - let me know if you have
> any objections.
Looks good, thanks Ingo!
--
Josh
Hi Ingo,
On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote:
> >
> > Does this fix it?
> >
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 6aaed251b4ed..0f94af3ccaaa 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -27,7 +27,7 @@ all: $(OBJTOOL)
> >
> > INCLUDES := -I$(srctree)/tools/include \
> > -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
> > - -I$(srctree)/tools/objtool/arch/$(HOSTARCH)/include
> > + -I$(srctree)/tools/objtool/arch/$(ARCH)/include
> > WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
> > CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> > LDFLAGS += -lelf $(LIBSUBCMD)
>
> Note, I created a commit out of this fix, with your SOB - let me know if you have
> any objections.
I applied this patch to linux-next today after the tip tree merge.
--
Cheers,
Stephen Rothwell
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Note, I created a commit out of this fix, with your SOB - let me know if you have
> > any objections.
>
> Only a small nit - I didn't bisect it, I just figured it out by
> inspection. Unfortunately, I don't have time to do bisections while
> building linux-next. :-(
>
> Not a biggie, though. Thanks for sorting this out.
Yeah, so while I knew that you didn't do the bisection the usual way, you still
got it right nevertheless, so the tag is well deserved! I'll add it as a
"Commit-identified-by" tag next time perhaps.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 4619 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call': net/rxrpc/call_object.c:661:3: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'? [-Werror=implicit-function-declaration] wake_up_atomic_t(&rxnet->nr_calls); ^~~~~~~~~~~~~~~~ wake_up_bit net/rxrpc/call_object.c: In function 'rxrpc_destroy_all_calls': net/rxrpc/call_object.c:728:2: error: implicit declaration of function 'wait_on_atomic_t'; did you mean 'wait_on_bit'? [-Werror=implicit-function-declaration] wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE); ^~~~~~~~~~~~~~~~ wait_on_bit net/rxrpc/call_object.c:728:37: error: 'atomic_t_wait' undeclared (first use in this function); did you mean 'atomic_long_t'? wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE); ^~~~~~~~~~~~~ atomic_long_t net/rxrpc/call_object.c:728:37: note: each undeclared identifier is reported only once for each function it appears in net/rxrpc/call_accept.c: In function 'rxrpc_discard_prealloc': net/rxrpc/call_accept.c:223:4: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'? [-Werror=implicit-function-declaration] wake_up_atomic_t(&rxnet->nr_conns); ^~~~~~~~~~~~~~~~ wake_up_bit Caused by commit 9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API") interacting with commits d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race") 31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects") from the net-next tree. Haven't we figured out how to remove/change APIs yet? :-( That tip tree commit is now in Linus' tree (merged since I started this morning) so the net-next tree will need the below patch (or something similar when it is merged. I have applied the following merge fix patch (this may need more work): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 3 Apr 2018 15:34:48 +1000 Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/rxrpc/call_accept.c | 2 +- net/rxrpc/call_object.c | 4 ++-- net/rxrpc/conn_object.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index f67017dcb25e..a9a9be5519b9 100644 --- a/net/rxrpc/call_accept.c +++ b/net/rxrpc/call_accept.c @@ -220,7 +220,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx) write_unlock(&rxnet->conn_lock); kfree(conn); if (atomic_dec_and_test(&rxnet->nr_conns)) - wake_up_atomic_t(&rxnet->nr_conns); + wake_up_var(&rxnet->nr_conns); tail = (tail + 1) & (size - 1); } diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c index f721c2b7e234..f6734d8cb01a 100644 --- a/net/rxrpc/call_object.c +++ b/net/rxrpc/call_object.c @@ -658,7 +658,7 @@ static void rxrpc_rcu_destroy_call(struct rcu_head *rcu) kfree(call->rxtx_annotations); kmem_cache_free(rxrpc_call_jar, call); if (atomic_dec_and_test(&rxnet->nr_calls)) - wake_up_atomic_t(&rxnet->nr_calls); + wake_up_var(&rxnet->nr_calls); } /* @@ -725,5 +725,5 @@ void rxrpc_destroy_all_calls(struct rxrpc_net *rxnet) write_unlock(&rxnet->call_lock); atomic_dec(&rxnet->nr_calls); - wait_on_atomic_t(&rxnet->nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE); + wait_var_event(&rxnet->nr_calls, !atomic_read(&rxnet->nr_calls)); } diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c index 0950ee3d26f5..4c77a78a252a 100644 --- a/net/rxrpc/conn_object.c +++ b/net/rxrpc/conn_object.c @@ -367,7 +367,7 @@ static void rxrpc_destroy_connection(struct rcu_head *rcu) rxrpc_put_peer(conn->params.peer); if (atomic_dec_and_test(&conn->params.local->rxnet->nr_conns)) - wake_up_atomic_t(&conn->params.local->rxnet->nr_conns); + wake_up_var(&conn->params.local->rxnet->nr_conns); rxrpc_put_local(conn->params.local); kfree(conn); @@ -482,6 +482,6 @@ void rxrpc_destroy_all_connections(struct rxrpc_net *rxnet) /* We need to wait for the connections to be destroyed by RCU as they * pin things that we still need to get rid of. */ - wait_on_atomic_t(&rxnet->nr_conns, atomic_t_wait, TASK_UNINTERRUPTIBLE); + wait_var_event(&rxnet->nr_conns, !atomic_read(&rxnet->nr_conns)); _leave(""); } -- 2.16.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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 :/
Peter Zijlstra <peterz@infradead.org> wrote:
> I figured that since there were only a handful of users it wasn't a
> popular API, also David very much knew of those patches changing it so
> could easily have pulled in the special tip/sched/wait branch :/
I'm not sure I could, since I have to base on net-next. I'm not sure what
DaveM's policy on that is.
Also, it might've been better not to simply erase the atomic_t wait API
immediately, but substitute wrappers for it to be removed one iteration hence.
David
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> + wait_var_event(&rxnet->nr_calls, !atomic_read(&rxnet->nr_calls));
I would prefer == 0 to ! as it's not really a true/false value.
But apart from that, it's looks okay and you can add my Reviewed-by.
David
On Tue, Apr 03, 2018 at 01:39:08PM +0100, David Howells wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > I figured that since there were only a handful of users it wasn't a
> > popular API, also David very much knew of those patches changing it so
> > could easily have pulled in the special tip/sched/wait branch :/
>
> I'm not sure I could, since I have to base on net-next. I'm not sure what
> DaveM's policy on that is.
>
> Also, it might've been better not to simply erase the atomic_t wait API
> immediately, but substitute wrappers for it to be removed one iteration hence.
Yeah, I know, but I really wasn't expecting new users of this thing, it
seemed like quite an exotic API with very limited users.
A well..
[-- Attachment #1: Type: text/plain, Size: 897 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 defconfig) failed like this: Invalid absolute R_X86_64_32S relocation: __end_rodata_aligned /kisskb/src/arch/x86/boot/compressed/Makefile:127: recipe for target 'arch/x86/boot/compressed/vmlinux.relocs' failed Caused by commit 39d668e04eda ("x86/mm/pti: Make pti_clone_kernel_text() compile on 32 bit") This was a build using gcc 4.6.3. the i386 defconfig also failed like this: Invalid absolute R_386_32 relocation: __end_rodata_aligned They started failing on next-20180723 (which is the first -next that contained the above commit). Sorry that we did not notice this earlier. At least the i386 defconfig build works with gcc 7.3.1. You can see the full build results here: http://kisskb.ellerman.id.au/kisskb/head/6b522b734da2950c368aae668f963b8925fb5545/ -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --] Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory Caused by commit 8d32588077bd ("locking/atomics: Check generated headers are up-to-date") I build with O= I have appplied the following fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 6 Nov 2018 11:37:10 +1100 Subject: [PATCH] fix for "locking/atomics: Check generated headers are up-to-date" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- Kbuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kbuild b/Kbuild index 47c9fe175bd9..780048056ac5 100644 --- a/Kbuild +++ b/Kbuild @@ -80,7 +80,7 @@ always += old-atomics targets += old-atomics quiet_cmd_atomics = CALL $< - cmd_atomics = $(CONFIG_SHELL) scripts/atomic/check-atomics.sh + cmd_atomics = $(CONFIG_SHELL) $< old-atomics: scripts/atomic/check-atomics.sh FORCE $(call cmd,atomics) -- 2.19.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data': drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration] rx_status->boottime_ns = ktime_get_boot_ns(); ^~~~~~~~~~~~~~~~~ ktime_get_raw_ns Caused by commit c11c75ec784e ("p54: Support boottime in scan results") from the wireless-drivers-next tree interacting with commit 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions") from the tip tree. I have added the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 25 Jun 2019 15:55:36 +1000 Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/net/wireless/intersil/p54/txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c index be6968454282..873fea59894f 100644 --- a/drivers/net/wireless/intersil/p54/txrx.c +++ b/drivers/net/wireless/intersil/p54/txrx.c @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb) fc = ((struct ieee80211_hdr *)skb->data)->frame_control; if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc)) - rx_status->boottime_ns = ktime_get_boot_ns(); + rx_status->boottime_ns = ktime_get_boottime_ns(); if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS)) p54_pspoll_workaround(priv, skb); -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration]
> rx_status->boottime_ns = ktime_get_boot_ns();
> ^~~~~~~~~~~~~~~~~
> ktime_get_raw_ns
>
> Caused by commit
>
> c11c75ec784e ("p54: Support boottime in scan results")
>
> from the wireless-drivers-next tree interacting with commit
>
> 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
>
> from the tip tree.
>
> I have added the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
>
> fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
> if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> - rx_status->boottime_ns = ktime_get_boot_ns();
> + rx_status->boottime_ns = ktime_get_boottime_ns();
Thanks for the report. Any suggestions how to handle this? Or do we let
Linus take care of this?
--
Kalle Valo
On Tue, 25 Jun 2019, Kalle Valo wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > ---
> > drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c
> > index be6968454282..873fea59894f 100644
> > --- a/drivers/net/wireless/intersil/p54/txrx.c
> > +++ b/drivers/net/wireless/intersil/p54/txrx.c
> > @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
> >
> > fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
> > if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> > - rx_status->boottime_ns = ktime_get_boot_ns();
> > + rx_status->boottime_ns = ktime_get_boottime_ns();
>
> Thanks for the report. Any suggestions how to handle this? Or do we let
> Linus take care of this?
As the core changes which cause this are in tip timers/core, I can just
pick that up and be done with it. Ok?
Thanks,
tglx
[-- Attachment #1: Type: text/plain, Size: 339 bytes --] Hi Kalle, On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote: > > Thanks for the report. Any suggestions how to handle this? Or do we let > Linus take care of this? Just let Linus take care of it ... mention it in the pull request ... I guess DaveM needs to know, right? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes: > On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote: >> >> Thanks for the report. Any suggestions how to handle this? Or do we let >> Linus take care of this? > > Just let Linus take care of it ... mention it in the pull request ... Thanks, I'll do that. > I guess DaveM needs to know, right? Yeah, this commit goes from wireless-drivers-next to net-next and from there to Linus. I'll inform Dave in my pull request. -- Kalle Valo
On Tue, 25 Jun 2019, Stephen Rothwell wrote:
> Hi Kalle,
>
> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
> >
> > Thanks for the report. Any suggestions how to handle this? Or do we let
> > Linus take care of this?
>
> Just let Linus take care of it ... mention it in the pull request ... I
> guess DaveM needs to know, right?
Ah. I didn't realize that this is a new commit in Kalle's tree. So yes
that's the right thing to do.
Thanks,
tglx
Thomas Gleixner <tglx@linutronix.de> writes:
> On Tue, 25 Jun 2019, Stephen Rothwell wrote:
>
>> Hi Kalle,
>>
>> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
>> >
>> > Thanks for the report. Any suggestions how to handle this? Or do we let
>> > Linus take care of this?
>>
>> Just let Linus take care of it ... mention it in the pull request ... I
>> guess DaveM needs to know, right?
>
> Ah. I didn't realize that this is a new commit in Kalle's tree. So yes
> that's the right thing to do.
Good, I'll do that then.
--
Kalle Valo
[-- Attachment #1: Type: text/plain, Size: 2174 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: fs/btrfs/ctree.c: In function '__tree_mod_log_insert': fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration] lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lockdep_assert_held_once Caused by commit 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()") interacting with commits 84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert") 283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping") from the btrfs-kdave tree. I have applied the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 2 Jul 2019 15:29:27 +1000 Subject: [PATCH] locking/lockdep: fix up for "Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- fs/btrfs/ctree.c | 2 +- fs/btrfs/extent_map.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index 99a585ede79d..9d1d0a926cb0 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -385,7 +385,7 @@ __tree_mod_log_insert(struct btrfs_fs_info *fs_info, struct tree_mod_elem *tm) struct rb_node *parent = NULL; struct tree_mod_elem *cur; - lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock); + lockdep_assert_held_write(&fs_info->tree_mod_log_lock); tm->seq = btrfs_inc_tree_mod_seq(fs_info); diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c index a73af4159495..9d30acca55e1 100644 --- a/fs/btrfs/extent_map.c +++ b/fs/btrfs/extent_map.c @@ -384,7 +384,7 @@ int add_extent_mapping(struct extent_map_tree *tree, { int ret = 0; - lockdep_assert_held_exclusive(&tree->lock); + lockdep_assert_held_write(&tree->lock); ret = tree_insert(&tree->map, em); if (ret) -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Jul 02, 2019 at 03:33:02PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/btrfs/ctree.c: In function '__tree_mod_log_insert':
> fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
> lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> lockdep_assert_held_once
>
> Caused by commit
>
> 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
>
> interacting with commits
>
> 84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert")
> 283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping")
I can move the patches out of the for-5.3 branch and send them
separately after the rename gets merged, they're merely adding the
assertion and otherwise do not affect the rest of the code.
Fixing that in another way would probably need more synchronization
between the branches but I don't think it's necessary in this case. The
next for-next snapshot branch will fix the compilation issue.
[-- Attachment #1: Type: text/plain, Size: 636 bytes --] Hi David, On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba <dsterba@suse.cz> wrote: > > I can move the patches out of the for-5.3 branch and send them > separately after the rename gets merged, they're merely adding the > assertion and otherwise do not affect the rest of the code. > > Fixing that in another way would probably need more synchronization > between the branches but I don't think it's necessary in this case. The > next for-next snapshot branch will fix the compilation issue. Its a simple enough conflict for Linus to fix up as long as someone tells him to expect it ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --] Hi David, On Tue, 2 Jul 2019 12:28:32 +0200 David Sterba <dsterba@suse.cz> wrote: > > On Tue, Jul 02, 2019 at 03:33:02PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the tip tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > fs/btrfs/ctree.c: In function '__tree_mod_log_insert': > > fs/btrfs/ctree.c:388:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration] > > lockdep_assert_held_exclusive(&fs_info->tree_mod_log_lock); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > lockdep_assert_held_once > > > > Caused by commit > > > > 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()") > > > > interacting with commits > > > > 84cd7723de7c ("btrfs: assert tree mod log lock in __tree_mod_log_insert") > > 283d2e443505 ("btrfs: assert extent map tree lock in add_extent_mapping") > > I can move the patches out of the for-5.3 branch and send them > separately after the rename gets merged, they're merely adding the > assertion and otherwise do not affect the rest of the code. > > Fixing that in another way would probably need more synchronization > between the branches but I don't think it's necessary in this case. The > next for-next snapshot branch will fix the compilation issue. I see that you removed those commits. The conflict is no more. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --] Hi all, On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data': > drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration] > rx_status->boottime_ns = ktime_get_boot_ns(); > ^~~~~~~~~~~~~~~~~ > ktime_get_raw_ns > > Caused by commit > > c11c75ec784e ("p54: Support boottime in scan results") > > from the wireless-drivers-next tree interacting with commit > > 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions") > > from the tip tree. > > I have added the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 25 Jun 2019 15:55:36 +1000 > Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/wireless/intersil/p54/txrx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c > index be6968454282..873fea59894f 100644 > --- a/drivers/net/wireless/intersil/p54/txrx.c > +++ b/drivers/net/wireless/intersil/p54/txrx.c > @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb) > > fc = ((struct ieee80211_hdr *)skb->data)->frame_control; > if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc)) > - rx_status->boottime_ns = ktime_get_boot_ns(); > + rx_status->boottime_ns = ktime_get_boottime_ns(); > > if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS)) > p54_pspoll_workaround(priv, skb); > -- > 2.20.1 I am still getting this conflict (the commit ids may have changed). Just a reminder in case you think Linus may need to know. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --] Hi all, On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data': > drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'? [-Werror=implicit-function-declaration] > rx_status->boottime_ns = ktime_get_boot_ns(); > ^~~~~~~~~~~~~~~~~ > ktime_get_raw_ns > > Caused by commit > > c11c75ec784e ("p54: Support boottime in scan results") > > from the wireless-drivers-next tree interacting with commit > > 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions") > > from the tip tree. > > I have added the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 25 Jun 2019 15:55:36 +1000 > Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/net/wireless/intersil/p54/txrx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/intersil/p54/txrx.c b/drivers/net/wireless/intersil/p54/txrx.c > index be6968454282..873fea59894f 100644 > --- a/drivers/net/wireless/intersil/p54/txrx.c > +++ b/drivers/net/wireless/intersil/p54/txrx.c > @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb) > > fc = ((struct ieee80211_hdr *)skb->data)->frame_control; > if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc)) > - rx_status->boottime_ns = ktime_get_boot_ns(); > + rx_status->boottime_ns = ktime_get_boottime_ns(); > > if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS)) > p54_pspoll_workaround(priv, skb); This patch is now needed in the merge between the net-next tree and Linus' tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/block/rbd.c: In function 'wake_lock_waiters': drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration] lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lockdep_assert_held_write Caused by commit 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()") interacting with commits 637cd060537d ("rbd: new exclusive lock wait/wake code") a2b1da09793d ("rbd: lock should be quiesced on reacquire") from the ceph tree. I have added the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 9 Jul 2019 16:46:12 +1000 Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c index 723c3ef4bd59..02216fbdb854 100644 --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result) struct rbd_img_request *img_req; dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result); - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); + lockdep_assert_held_write(&rbd_dev->lock_rwsem); cancel_delayed_work(&rbd_dev->lock_dwork); if (!completion_done(&rbd_dev->acquire_wait)) { @@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev) bool need_wait; dout("%s rbd_dev %p\n", __func__, rbd_dev); - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); + lockdep_assert_held_write(&rbd_dev->lock_rwsem); if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED) return false; -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --] Hi all, On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/block/rbd.c: In function 'wake_lock_waiters': > drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration] > lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > lockdep_assert_held_write > > Caused by commit > > 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()") > > interacting with commits > > 637cd060537d ("rbd: new exclusive lock wait/wake code") > a2b1da09793d ("rbd: lock should be quiesced on reacquire") > > from the ceph tree. > > I have added the following merge fix patch for today. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 9 Jul 2019 16:46:12 +1000 > Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/block/rbd.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c > index 723c3ef4bd59..02216fbdb854 100644 > --- a/drivers/block/rbd.c > +++ b/drivers/block/rbd.c > @@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result) > struct rbd_img_request *img_req; > > dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result); > - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); > + lockdep_assert_held_write(&rbd_dev->lock_rwsem); > > cancel_delayed_work(&rbd_dev->lock_dwork); > if (!completion_done(&rbd_dev->acquire_wait)) { > @@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev) > bool need_wait; > > dout("%s rbd_dev %p\n", __func__, rbd_dev); > - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem); > + lockdep_assert_held_write(&rbd_dev->lock_rwsem); > > if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED) > return false; This fix now needs to be applied to the merge of the ceph tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Jul 10, 2019 at 2:01 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Tue, 9 Jul 2019 16:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/block/rbd.c: In function 'wake_lock_waiters':
> > drivers/block/rbd.c:3933:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_write'? [-Werror=implicit-function-declaration]
> > lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > lockdep_assert_held_write
> >
> > Caused by commit
> >
> > 9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> >
> > interacting with commits
> >
> > 637cd060537d ("rbd: new exclusive lock wait/wake code")
> > a2b1da09793d ("rbd: lock should be quiesced on reacquire")
> >
> > from the ceph tree.
> >
> > I have added the following merge fix patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 9 Jul 2019 16:46:12 +1000
> > Subject: [PATCH] rbd: fix up for lockdep_assert_held_exclusive rename
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/block/rbd.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> > index 723c3ef4bd59..02216fbdb854 100644
> > --- a/drivers/block/rbd.c
> > +++ b/drivers/block/rbd.c
> > @@ -3930,7 +3930,7 @@ static void wake_lock_waiters(struct rbd_device *rbd_dev, int result)
> > struct rbd_img_request *img_req;
> >
> > dout("%s rbd_dev %p result %d\n", __func__, rbd_dev, result);
> > - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> > + lockdep_assert_held_write(&rbd_dev->lock_rwsem);
> >
> > cancel_delayed_work(&rbd_dev->lock_dwork);
> > if (!completion_done(&rbd_dev->acquire_wait)) {
> > @@ -4209,7 +4209,7 @@ static bool rbd_quiesce_lock(struct rbd_device *rbd_dev)
> > bool need_wait;
> >
> > dout("%s rbd_dev %p\n", __func__, rbd_dev);
> > - lockdep_assert_held_exclusive(&rbd_dev->lock_rwsem);
> > + lockdep_assert_held_write(&rbd_dev->lock_rwsem);
> >
> > if (rbd_dev->lock_state != RBD_LOCK_STATE_LOCKED)
> > return false;
>
> This fix now needs to be applied to the merge of the ceph tree.
Hi Stephen,
Yes, that is what I figured would happen. I assume you would keep
carrying this fixup until the ceph tree is merged.
Thanks,
Ilya
[-- Attachment #1: Type: text/plain, Size: 264 bytes --] Hi Ilya, On Wed, 10 Jul 2019 20:21:33 +0200 Ilya Dryomov <idryomov@gmail.com> wrote: > > Yes, that is what I figured would happen. I assume you would keep > carrying this fixup until the ceph tree is merged. Of course. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/android/vsoc.c: In function 'handle_vsoc_cond_wait': drivers/staging/android/vsoc.c:440:33: error: passing argument 1 of 'hrtimer_init_sleeper_on_stack' from incompatible pointer type [-Werror=incompatible-pointer-types] hrtimer_init_sleeper_on_stack(&to, CLOCK_MONOTONIC, ^~~ In file included from include/linux/pm.h:16, from include/linux/device.h:23, from include/linux/dma-mapping.h:7, from drivers/staging/android/vsoc.c:19: include/linux/hrtimer.h:381:67: note: expected 'struct hrtimer_sleeper *' but argument is of type 'struct hrtimer_sleeper **' extern void hrtimer_init_sleeper_on_stack(struct hrtimer_sleeper *sl, ~~~~~~~~~~~~~~~~~~~~~~~~^~ Caused by commit 82e18bace3dd ("hrtimer: Consolidate hrtimer_init() + hrtimer_init_sleeper() calls") I have added the following patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 1 Aug 2019 13:33:44 +1000 Subject: [PATCH] hrtimer: fix typo in hrtimer_init_sleeper_on_stack() conversion Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/staging/android/vsoc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c index 4f7e6c1dce42..1240bb0317d9 100644 --- a/drivers/staging/android/vsoc.c +++ b/drivers/staging/android/vsoc.c @@ -437,7 +437,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct vsoc_cond_wait *arg) return -EINVAL; wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec); - hrtimer_init_sleeper_on_stack(&to, CLOCK_MONOTONIC, + hrtimer_init_sleeper_on_stack(to, CLOCK_MONOTONIC, HRTIMER_MODE_ABS); hrtimer_set_expires_range_ns(&to->timer, wake_time, current->timer_slack_ns); -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 625 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: kernel/locking/mutex-debug.c: In function 'debug_mutex_lock_common': kernel/locking/mutex-debug.c:32:42: error: dereferencing pointer to incomplete type 'struct mutex_waiter' memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter)); ^~~~~~~ Caused by commit 5f35d5a66b3e ("locking/mutex: Make __mutex_owner static to mutex.c") I have reverted that commit for today. BTW, there is another reference to mutex_waiter in sched.h! -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4410 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from sound/soc/intel/boards/sof_rt5682.c:23: sound/soc/intel/boards/../common/soc-intel-quirks.h: In function 'soc_intel_is_cml': sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'? SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ sound/soc/intel/boards/../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/intel/boards/../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ sound/soc/intel/boards/../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ In file included from sound/soc/intel/atom/sst/sst_acpi.c:35: sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h: In function 'soc_intel_is_cml': sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: error: 'INTEL_FAM6_KABYLAKE_MOBILE' undeclared (first use in this function); did you mean 'INTEL_FAM6_KABYLAKE_L'? SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:23: note: each undeclared identifier is reported only once for each function it appears in SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:18:44: note: in definition of macro 'ICPU' #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } ^~~~~ sound/soc/intel/atom/sst/../../common/soc-intel-quirks.h:39:1: note: in expansion of macro 'SOC_INTEL_IS_CPU' SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); ^~~~~~~~~~~~~~~~ Caused by commit af239c44e3f9 ("x86/intel: Aggregate big core mobile naming") interacting with commit c643c189f0fe ("ASoC: Intel: boards: Add Cometlake machine driver support") from the sound-asoc tree. I have added the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 29 Aug 2019 16:08:49 +1000 Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- sound/soc/intel/common/soc-intel-quirks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h index e6357d306cb8..863a477d3405 100644 --- a/sound/soc/intel/common/soc-intel-quirks.h +++ b/sound/soc/intel/common/soc-intel-quirks.h @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT); SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT); SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT); SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS); -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE); +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L); static inline bool soc_intel_is_byt_cr(struct platform_device *pdev) { -- 2.20.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Aug 2019 16:08:49 +1000
> Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> sound/soc/intel/common/soc-intel-quirks.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> index e6357d306cb8..863a477d3405 100644
> --- a/sound/soc/intel/common/soc-intel-quirks.h
> +++ b/sound/soc/intel/common/soc-intel-quirks.h
> @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
> SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
> SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
> SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
ARGHH... rebase again?
On Thu, 29 Aug 2019, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 29 Aug 2019 16:08:49 +1000
> > Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > sound/soc/intel/common/soc-intel-quirks.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> > index e6357d306cb8..863a477d3405 100644
> > --- a/sound/soc/intel/common/soc-intel-quirks.h
> > +++ b/sound/soc/intel/common/soc-intel-quirks.h
> > @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
> > SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
> > SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
> > SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> > -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> > +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
>
> ARGHH... rebase again?
No. This is a conflict with the sound tree which added the MOBILE
thingy. So what you could do for now is
#define INTEL_FAM6_KABYLAKE_MOBILE INTEL_FAM6_KABYLAKE_L
and remove that after both trees have hit mainline, i.e. around rc1.
Thanks,
tglx
On Thu, Aug 29, 2019 at 02:24:24PM +0200, Thomas Gleixner wrote:
> On Thu, 29 Aug 2019, Peter Zijlstra wrote:
> > On Thu, Aug 29, 2019 at 04:20:12PM +1000, Stephen Rothwell wrote:
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 29 Aug 2019 16:08:49 +1000
> > > Subject: [PATCH] ASoC: Intel: boards: merge fix for INTEL_FAM6_KABYLAKE_MOBILE -> INTEL_FAM6_KABYLAKE_L change
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > sound/soc/intel/common/soc-intel-quirks.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h
> > > index e6357d306cb8..863a477d3405 100644
> > > --- a/sound/soc/intel/common/soc-intel-quirks.h
> > > +++ b/sound/soc/intel/common/soc-intel-quirks.h
> > > @@ -36,7 +36,7 @@ SOC_INTEL_IS_CPU(byt, INTEL_FAM6_ATOM_SILVERMONT);
> > > SOC_INTEL_IS_CPU(cht, INTEL_FAM6_ATOM_AIRMONT);
> > > SOC_INTEL_IS_CPU(apl, INTEL_FAM6_ATOM_GOLDMONT);
> > > SOC_INTEL_IS_CPU(glk, INTEL_FAM6_ATOM_GOLDMONT_PLUS);
> > > -SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_MOBILE);
> > > +SOC_INTEL_IS_CPU(cml, INTEL_FAM6_KABYLAKE_L);
> >
> > ARGHH... rebase again?
>
> No. This is a conflict with the sound tree which added the MOBILE
> thingy. So what you could do for now is
Yes, SFR clarified that. This is a case of me doing email before waking
up.
[-- Attachment #1: Type: text/plain, Size: 4232 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume': drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release" passed 3 arguments, but takes just 2 183 | mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_); | ^ In file included from include/linux/spinlock_types.h:18, from include/linux/spinlock.h:83, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from include/linux/io-mapping.h:10, from drivers/gpu/drm/i915/i915_drv.h:36, from drivers/gpu/drm/i915/gt/intel_gt_pm.c:7: include/linux/lockdep.h:605: note: macro "mutex_release" defined here 605 | #define mutex_release(l, i) lock_release(l, i) | drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__context_pin_release': drivers/gpu/drm/i915/gt/intel_lrc.c:245:51: error: macro "mutex_release" passed 3 arguments, but takes just 2 245 | mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_); | ^ In file included from include/linux/hardirq.h:6, from include/linux/interrupt.h:11, from drivers/gpu/drm/i915/gt/intel_lrc.c:134: include/linux/lockdep.h:605: note: macro "mutex_release" defined here 605 | #define mutex_release(l, i) lock_release(l, i) | Caused by commit 5facae4f3549 ("locking/lockdep: Remove unused @nested argument from lock_release()") interacting with commits dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()") fcde8c7eea60 ("drm/i915/selftests: Exercise potential false lite-restore") b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") from the drm tree. I added the following merge fix patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 10 Oct 2019 13:08:43 +1100 Subject: [PATCH] drm/i915: update for mutex_release API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- drivers/gpu/drm/i915/i915_active.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c index b52e2ba3d092..d195e05a701f 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c @@ -180,7 +180,7 @@ int intel_gt_resume(struct intel_gt *gt) GEM_BUG_ON(!intel_context_is_pinned(ce)); mutex_acquire(&ce->pin_mutex.dep_map, 0, 0, _THIS_IP_); ce->ops->reset(ce); - mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_); + mutex_release(&ce->pin_mutex.dep_map, _THIS_IP_); } engine->serial++; /* kernel context lost */ diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index a2155d6bcdd2..aa61b0101bf8 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -242,7 +242,7 @@ static void __context_pin_acquire(struct intel_context *ce) static void __context_pin_release(struct intel_context *ce) { - mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_); + mutex_release(&ce->pin_mutex.dep_map, _RET_IP_); } static void mark_eio(struct i915_request *rq) diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index aa37c07004b9..a47387174434 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f) mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_); if (!__i915_active_fence_set(&ref->excl, f)) atomic_inc(&ref->count); - mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_); + mutex_release(&ref->mutex.dep_map, _THIS_IP_); } bool i915_active_acquire_if_busy(struct i915_active *ref) -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
> drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release" passed 3 arguments, but takes just 2
> 183 | mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
> | ^
> In file included from include/linux/spinlock_types.h:18,
> from include/linux/spinlock.h:83,
> from include/linux/mmzone.h:8,
> from include/linux/gfp.h:6,
> from include/linux/slab.h:15,
> from include/linux/io-mapping.h:10,
> from drivers/gpu/drm/i915/i915_drv.h:36,
> from drivers/gpu/drm/i915/gt/intel_gt_pm.c:7:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
> 605 | #define mutex_release(l, i) lock_release(l, i)
> |
> drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__context_pin_release':
> drivers/gpu/drm/i915/gt/intel_lrc.c:245:51: error: macro "mutex_release" passed 3 arguments, but takes just 2
> 245 | mutex_release(&ce->pin_mutex.dep_map, 0, _RET_IP_);
> | ^
> In file included from include/linux/hardirq.h:6,
> from include/linux/interrupt.h:11,
> from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
> include/linux/lockdep.h:605: note: macro "mutex_release" defined here
> 605 | #define mutex_release(l, i) lock_release(l, i)
> |
>
> Caused by commit
>
> 5facae4f3549 ("locking/lockdep: Remove unused @nested argument from lock_release()")
>
> interacting with commits
>
> dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()")
> fcde8c7eea60 ("drm/i915/selftests: Exercise potential false lite-restore")
> b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
>
> from the drm tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 10 Oct 2019 13:08:43 +1100
> Subject: [PATCH] drm/i915: update for mutex_release API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
I suspect -next will have to carry this semantic merge conflict
resolution until the DRM tree is merged upstream.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 311 bytes --] Hi Ingo, On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar <mingo@kernel.org> wrote: > > I suspect -next will have to carry this semantic merge conflict > resolution until the DRM tree is merged upstream. Yep, its not a real problem, I get a few like this every cycle. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Oct 10, 2019 at 10:23:21PM +1100, Stephen Rothwell wrote: > Hi Ingo, > > On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar <mingo@kernel.org> wrote: > > > > I suspect -next will have to carry this semantic merge conflict > > resolution until the DRM tree is merged upstream. > > Yep, its not a real problem, I get a few like this every cycle. Yeah totally within expectations when I acked that cleanup patch. We'll probably have a few more lockdep annotation patches/changes that will conflict in drm. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[-- Attachment #1: Type: text/plain, Size: 384 bytes --] Hi all, After merging the tip tree, today's linux-next build (native perf) failed like this: make: execvp: ./check-headers.sh: Permission denied Caused by commit 05f2f277053d ("Merge branch 'x86/core'") which somehow removed execute permissions from tools/perf/check-headers.sh I added a commit to reenable execute permissions. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (native perf)
> failed like this:
>
> make: execvp: ./check-headers.sh: Permission denied
>
> Caused by commit
>
> 05f2f277053d ("Merge branch 'x86/core'")
>
> which somehow removed execute permissions from tools/perf/check-headers.sh
>
> I added a commit to reenable execute permissions.
Hm, that was a weird merge mishap - sorry about that, should go away in
the next -next iteration.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 237 bytes --] Hi Ingo, On Mon, 21 Oct 2019 07:51:41 +0200 Ingo Molnar <mingo@kernel.org> wrote: > > Hm, that was a weird merge mishap - sorry about that, should go away in > the next -next iteration. Thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Hi all, On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > I added the following merge fix patch for today: > This patch is now just: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 10 Oct 2019 13:08:43 +1100 Subject: [PATCH] drm/i915: update for mutex_release API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/gpu/drm/i915/i915_active.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index aa37c07004b9..a47387174434 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f) mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_); if (!__i915_active_fence_set(&ref->excl, f)) atomic_inc(&ref->count); - mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_); + mutex_release(&ref->mutex.dep_map, _THIS_IP_); } bool i915_active_acquire_if_busy(struct i915_active *ref) -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/crypto/blake2s-core.S: Assembler messages: arch/x86/crypto/blake2s-core.S:50: Error: invalid character '(' in mnemonic arch/x86/crypto/blake2s-core.S:176: Error: invalid character '(' in mnemonic arch/x86/crypto/blake2s-core.S:180: Error: invalid character '(' in mnemonic arch/x86/crypto/blake2s-core.S:257: Error: invalid character '(' in mnemonic Caused by commit ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation") from the crypto tree interacting with commit 6dcc5627f6ae ("x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*") from the tip tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 18 Nov 2019 14:00:40 +1100 Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/crypto/blake2s-core.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S index 8591938eee26..24910b766bdd 100644 --- a/arch/x86/crypto/blake2s-core.S +++ b/arch/x86/crypto/blake2s-core.S @@ -47,7 +47,7 @@ SIGMA2: .text #ifdef CONFIG_AS_SSSE3 -ENTRY(blake2s_compress_ssse3) +SYM_FUNC_START(blake2s_compress_ssse3) testq %rdx,%rdx je .Lendofloop movdqu (%rdi),%xmm0 @@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3) movdqu %xmm14,0x20(%rdi) .Lendofloop: ret -ENDPROC(blake2s_compress_ssse3) +SYM_FUNC_END(blake2s_compress_ssse3) #endif /* CONFIG_AS_SSSE3 */ #ifdef CONFIG_AS_AVX512 -ENTRY(blake2s_compress_avx512) +SYM_FUNC_START(blake2s_compress_avx512) vmovdqu (%rdi),%xmm0 vmovdqu 0x10(%rdi),%xmm1 vmovdqu 0x20(%rdi),%xmm4 @@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512) vmovdqu %xmm4,0x20(%rdi) vzeroupper retq -ENDPROC(blake2s_compress_avx512) +SYM_FUNC_END(blake2s_compress_avx512) #endif /* CONFIG_AS_AVX512 */ -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 1508 bytes --] On 18. 11. 19, 4:11, Stephen Rothwell wrote: > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 18 Nov 2019 14:00:40 +1100 > Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/crypto/blake2s-core.S | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S > index 8591938eee26..24910b766bdd 100644 > --- a/arch/x86/crypto/blake2s-core.S > +++ b/arch/x86/crypto/blake2s-core.S > @@ -47,7 +47,7 @@ SIGMA2: > > .text > #ifdef CONFIG_AS_SSSE3 > -ENTRY(blake2s_compress_ssse3) > +SYM_FUNC_START(blake2s_compress_ssse3) > testq %rdx,%rdx > je .Lendofloop > movdqu (%rdi),%xmm0 > @@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3) > movdqu %xmm14,0x20(%rdi) > .Lendofloop: > ret > -ENDPROC(blake2s_compress_ssse3) > +SYM_FUNC_END(blake2s_compress_ssse3) > #endif /* CONFIG_AS_SSSE3 */ > > #ifdef CONFIG_AS_AVX512 > -ENTRY(blake2s_compress_avx512) > +SYM_FUNC_START(blake2s_compress_avx512) > vmovdqu (%rdi),%xmm0 > vmovdqu 0x10(%rdi),%xmm1 > vmovdqu 0x20(%rdi),%xmm4 > @@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512) > vmovdqu %xmm4,0x20(%rdi) > vzeroupper > retq > -ENDPROC(blake2s_compress_avx512) > +SYM_FUNC_END(blake2s_compress_avx512) > #endif /* CONFIG_AS_AVX512 */ Hi, FWIW LGTM. thanks, -- js suse labs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On Mon, Nov 18, 2019 at 02:11:10PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/crypto/blake2s-core.S: Assembler messages: > arch/x86/crypto/blake2s-core.S:50: Error: invalid character '(' in mnemonic > arch/x86/crypto/blake2s-core.S:176: Error: invalid character '(' in mnemonic > arch/x86/crypto/blake2s-core.S:180: Error: invalid character '(' in mnemonic > arch/x86/crypto/blake2s-core.S:257: Error: invalid character '(' in mnemonic > > Caused by commit > > ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation") > > from the crypto tree interacting with commit > > 6dcc5627f6ae ("x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*") > > from the tip tree. > > I have applied the following merge fix patch. Thanks. I need to remember to point Linus to it when I send the pull request next week so that he's aware and can apply your patch when merging the crypto tree. Lemme CC him now too, as an FYI. > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 18 Nov 2019 14:00:40 +1100 > Subject: [PATCH] fix up for "x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*" <--- add a commit message blurb here pls. > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/crypto/blake2s-core.S | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/crypto/blake2s-core.S b/arch/x86/crypto/blake2s-core.S > index 8591938eee26..24910b766bdd 100644 > --- a/arch/x86/crypto/blake2s-core.S > +++ b/arch/x86/crypto/blake2s-core.S > @@ -47,7 +47,7 @@ SIGMA2: > > .text > #ifdef CONFIG_AS_SSSE3 > -ENTRY(blake2s_compress_ssse3) > +SYM_FUNC_START(blake2s_compress_ssse3) > testq %rdx,%rdx > je .Lendofloop > movdqu (%rdi),%xmm0 > @@ -173,11 +173,11 @@ ENTRY(blake2s_compress_ssse3) > movdqu %xmm14,0x20(%rdi) > .Lendofloop: > ret > -ENDPROC(blake2s_compress_ssse3) > +SYM_FUNC_END(blake2s_compress_ssse3) > #endif /* CONFIG_AS_SSSE3 */ > > #ifdef CONFIG_AS_AVX512 > -ENTRY(blake2s_compress_avx512) > +SYM_FUNC_START(blake2s_compress_avx512) > vmovdqu (%rdi),%xmm0 > vmovdqu 0x10(%rdi),%xmm1 > vmovdqu 0x20(%rdi),%xmm4 > @@ -254,5 +254,5 @@ ENTRY(blake2s_compress_avx512) > vmovdqu %xmm4,0x20(%rdi) > vzeroupper > retq > -ENDPROC(blake2s_compress_avx512) > +SYM_FUNC_END(blake2s_compress_avx512) > #endif /* CONFIG_AS_AVX512 */ > -- > 2.23.0 > > -- > Cheers, > Stephen Rothwell -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/trace/define_trace.h:102, from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502, from drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c:29: include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:476:52: error: expected expression before ';' token 476 | __string(ring, sched_job->base.sched->name); | ^ include/trace/trace_events.h:435:2: note: in definition of macro 'DECLARE_EVENT_CLASS' 435 | tstruct \ | ^~~~~~~ include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS' 77 | PARAMS(tstruct), \ | ^~~~~~ include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:472:1: note: in expansion of macro 'TRACE_EVENT' 472 | TRACE_EVENT(amdgpu_ib_pipe_sync, | ^~~~~~~~~~~ include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:475:6: note: in expansion of macro 'TP_STRUCT__entry' 475 | TP_STRUCT__entry( | ^~~~~~~~~~~~~~~~ Caused by commit 2c2fdb8bca29 ("drm/amdgpu: fix amdgpu trace event print string format error") from the drm tree interacting with commit 60fdad00827c ("ftrace: Rework event_create_dir()") from the tip tree. I have added the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 21 Nov 2019 14:46:00 +1100 Subject: [PATCH] merge fix for "ftrace: Rework event_create_dir()" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h index f940526c5889..63e734a125fb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h @@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync, TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence), TP_ARGS(sched_job, fence), TP_STRUCT__entry( - __string(ring, sched_job->base.sched->name); + __string(ring, sched_job->base.sched->name) __field(uint64_t, id) __field(struct dma_fence *, fence) __field(uint64_t, ctx) -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 804 bytes --] On Thu, Nov 21, 2019 at 02:54:03PM +1100, Stephen Rothwell wrote: > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > index f940526c5889..63e734a125fb 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > @@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync, > TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence), > TP_ARGS(sched_job, fence), > TP_STRUCT__entry( > - __string(ring, sched_job->base.sched->name); > + __string(ring, sched_job->base.sched->name) > __field(uint64_t, id) > __field(struct dma_fence *, fence) > __field(uint64_t, ctx) Correct, ';' there is invalid and now results in very verbose compile errors :-) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On Wed, Nov 20, 2019 at 10:54 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from include/trace/define_trace.h:102, > from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502, > from drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c:29: > include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:476:52: error: expected expression before ';' token > 476 | __string(ring, sched_job->base.sched->name); > | ^ > include/trace/trace_events.h:435:2: note: in definition of macro 'DECLARE_EVENT_CLASS' > 435 | tstruct \ > | ^~~~~~~ > include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS' > 77 | PARAMS(tstruct), \ > | ^~~~~~ > include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:472:1: note: in expansion of macro 'TRACE_EVENT' > 472 | TRACE_EVENT(amdgpu_ib_pipe_sync, > | ^~~~~~~~~~~ > include/trace/../../drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:475:6: note: in expansion of macro 'TP_STRUCT__entry' > 475 | TP_STRUCT__entry( > | ^~~~~~~~~~~~~~~~ > > Caused by commit > > 2c2fdb8bca29 ("drm/amdgpu: fix amdgpu trace event print string format error") > > from the drm tree interacting with commit > > 60fdad00827c ("ftrace: Rework event_create_dir()") > > from the tip tree. > > I have added the following merge fix patch: Applied. Thanks! Alex > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 21 Nov 2019 14:46:00 +1100 > Subject: [PATCH] merge fix for "ftrace: Rework event_create_dir()" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > index f940526c5889..63e734a125fb 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > @@ -473,7 +473,7 @@ TRACE_EVENT(amdgpu_ib_pipe_sync, > TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence), > TP_ARGS(sched_job, fence), > TP_STRUCT__entry( > - __string(ring, sched_job->base.sched->name); > + __string(ring, sched_job->base.sched->name) > __field(uint64_t, id) > __field(struct dma_fence *, fence) > __field(uint64_t, ctx) > -- > 2.23.0 > > -- > Cheers, > Stephen Rothwell > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --] Hi all, On Wed, 6 Nov 2019 13:53:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > I added the following merge fix patch for today: > > > > This patch is now just: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 10 Oct 2019 13:08:43 +1100 > Subject: [PATCH] drm/i915: update for mutex_release API change > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/gpu/drm/i915/i915_active.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c > index aa37c07004b9..a47387174434 100644 > --- a/drivers/gpu/drm/i915/i915_active.c > +++ b/drivers/gpu/drm/i915/i915_active.c > @@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f) > mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_); > if (!__i915_active_fence_set(&ref->excl, f)) > atomic_inc(&ref->count); > - mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_); > + mutex_release(&ref->mutex.dep_map, _THIS_IP_); > } > > bool i915_active_acquire_if_busy(struct i915_active *ref) > -- > 2.23.0 This merge fix patch is now needed for the merge between the drm tree and Linus' tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/power/reset/sc27xx-poweroff.c: In function 'sc27xx_poweroff_shutdown': drivers/power/reset/sc27xx-poweroff.c:38:4: error: implicit declaration of function 'cpu_down' [-Werror=implicit-function-declaration] 38 | cpu_down(cpu); | ^~~~~~~~ Caused by commit 33c3736ec888 ("cpu/hotplug: Hide cpu_up/down()") interacting with commit 274afbc3ad33 ("power: reset: sc27xx: Change to use cpu_down()") from the battery tree. I have added the following merge fix patch: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 26 Mar 2020 13:42:00 +1100 Subject: [PATCH] power: reset: sc27xx: use remove_cpu instead of cpu_down Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/power/reset/sc27xx-poweroff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c index 69863074daf6..90287c31992c 100644 --- a/drivers/power/reset/sc27xx-poweroff.c +++ b/drivers/power/reset/sc27xx-poweroff.c @@ -35,7 +35,7 @@ static void sc27xx_poweroff_shutdown(void) for_each_online_cpu(cpu) { if (cpu != smp_processor_id()) - cpu_down(cpu); + remove_cpu(cpu); } #endif } -- 2.25.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen On 03/26/20 13:52, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/power/reset/sc27xx-poweroff.c: In function 'sc27xx_poweroff_shutdown': > drivers/power/reset/sc27xx-poweroff.c:38:4: error: implicit declaration of function 'cpu_down' [-Werror=implicit-function-declaration] > 38 | cpu_down(cpu); > | ^~~~~~~~ > > Caused by commit > > 33c3736ec888 ("cpu/hotplug: Hide cpu_up/down()") > > interacting with commit > > 274afbc3ad33 ("power: reset: sc27xx: Change to use cpu_down()") > > from the battery tree. > > I have added the following merge fix patch: Your merge fix looks correct. Though the original code is missing error handling if offlining the cpu failed for one reason or another. I don't know the details, but something feels off about the driver having to bring cpus down. Thanks -- Qais Yousef > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 26 Mar 2020 13:42:00 +1100 > Subject: [PATCH] power: reset: sc27xx: use remove_cpu instead of cpu_down > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/power/reset/sc27xx-poweroff.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c > index 69863074daf6..90287c31992c 100644 > --- a/drivers/power/reset/sc27xx-poweroff.c > +++ b/drivers/power/reset/sc27xx-poweroff.c > @@ -35,7 +35,7 @@ static void sc27xx_poweroff_shutdown(void) > > for_each_online_cpu(cpu) { > if (cpu != smp_processor_id()) > - cpu_down(cpu); > + remove_cpu(cpu); > } > #endif > } > -- > 2.25.0 > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 936 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: ld: warning: discarding dynamic section .rela.data.rel.ro lots of similar warnings, followed by `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o `.exit.text' referenced in section `__bug_table' of drivers/macintosh/windfarm_core.o: defined in discarded section `.exit.text' of drivers/macintosh/windfarm_core.o `.exit.text' referenced in section `__bug_table' of drivers/i2c/i2c-core-base.o: defined in discarded section `.exit.text' of drivers/i2c/i2c-core-base.o Caused by commit 72cb2113c1bb ("vmlinux.lds: Discard .note.gnu.property sections in generic NOTES") I don't see why, but reverting that commit fixes the build warnings and failure. I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --] On Sun, Mar 29, 2020 at 8:35 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > ld: warning: discarding dynamic section .rela.data.rel.ro > > lots of similar warnings, followed by > > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o > `.exit.text' referenced in section `__bug_table' of drivers/macintosh/windfarm_core.o: defined in discarded section `.exit.text' of drivers/macintosh/windfarm_core.o > `.exit.text' referenced in section `__bug_table' of drivers/i2c/i2c-core-base.o: defined in discarded section `.exit.text' of drivers/i2c/i2c-core-base.o > > Caused by commit > > 72cb2113c1bb ("vmlinux.lds: Discard .note.gnu.property sections in generic NOTES") > > I don't see why, but reverting that commit fixes the build warnings > and failure. Please see my enclosing email. Is anyone from PPC community reading emails? > I have reverted that commit for today. > -- > Cheers, > Stephen Rothwell -- H.J. [-- Attachment #2: RFA [PPC kernel] Avoid upcoming PPC kernel build failure.eml --] [-- Type: message/rfc822, Size: 5715 bytes --] From: "H.J. Lu" <hjl.tools@gmail.com> To: Yu-cheng Yu <yu-cheng.yu@intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, Kees Cook <keescook@chromium.org> Subject: RFA [PPC kernel] Avoid upcoming PPC kernel build failure Date: Fri, 27 Mar 2020 10:36:36 -0700 Message-ID: <CAMe9rOpKPYe55=9c1smGwBZBhRbk8PjpdJZ-xQ7RDXjN81gKug@mail.gmail.com> On Fri, Mar 27, 2020 at 7:54 AM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote: > > On Thu, 2020-02-06 at 04:55 -0800, H.J. Lu wrote: > > On Wed, Feb 5, 2020 at 7:26 PM Michael Ellerman <mpe@ellerman.id.au> wrote: > > > "H.J. Lu" <hjl.tools@gmail.com> writes: > > > > On Tue, Feb 4, 2020 at 3:37 PM kbuild test robot <lkp@intel.com> wrote: > > > > > tree: https://github.com/yyu168/linux_cet.git cet > > > > > head: bba707cc4715c1036b6561ab38b16747f9c49cfa > > > > > commit: 71bb971dd76eeacd351690f28864ad5c5bec3691 [55/58] Discard .note.gnu.property sections in generic NOTES > > > > > config: powerpc-rhel-kconfig (attached as .config) > > > > > compiler: powerpc64le-linux-gcc (GCC) 7.5.0 > > > > > reproduce: > > > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > > > > chmod +x ~/bin/make.cross > > > > > git checkout 71bb971dd76eeacd351690f28864ad5c5bec3691 > > > > > # save the attached .config to linux build tree > > > > > GCC_VERSION=7.5.0 make.cross ARCH=powerpc > > > > > > > > > > If you fix the issue, kindly add following tag > > > > > Reported-by: kbuild test robot <lkp@intel.com> > > > > > > > > > > All warnings (new ones prefixed by >>): > > > > > > > > > > powerpc64le-linux-ld: warning: discarding dynamic section .rela___ksymtab_gpl+__wait_rcu_gp > > > > > > > > arch/powerpc/kernel/vmlinux.lds.S has > > > > > > > > .rela.dyn : AT(ADDR(.rela.dyn) - (0xc000000000000000 -0x00000000)) > > > > { > > > > __rela_dyn_start = .; > > > > *(.rela*) <<<<<<<< Keep .rela* sections > > > > } > > > > > > The above is inside #ifdef CONFIG_RELOCATABLE > > > > > > > ... > > > > /DISCARD/ : { > > > > *(*.EMB.apuinfo) > > > > *(.glink .iplt .plt .rela* .comment) > > > > ^^^^ Discard .rela* sections. But it is ignored. > > > > *(.gnu.version*) > > > > *(.gnu.attributes) > > > > *(.eh_frame) > > > > } > > > > > > But that is not #ifdef'ed at all. > > > > > > > With my > > > > > > > > ommit 71bb971dd76eeacd351690f28864ad5c5bec3691 > > > > Author: H.J. Lu <hjl.tools@gmail.com> > > > > Date: Thu Jan 30 12:39:09 2020 -0800 > > > > > > > > Discard .note.gnu.property sections in generic NOTES > > > > > > > > With the command-line option, -mx86-used-note=yes, the x86 assembler > > > > in binutils 2.32 and above generates a program property note in a note > > > > section, .note.gnu.property, to encode used x86 ISAs and features. But > > > > kernel linker script only contains a single NOTE segment: > > > > > > > > /DISCARD/ : { *(.note.gnu.property) } > > > > > > > > is placed before > > > > > > > > .rela.dyn : AT(ADDR(.rela.dyn) - (0xc000000000000000 -0x00000000)) > > > > { > > > > __rela_dyn_start = .; > > > > *(.rela*) <<<<<<<< Keep .rela* sections > > > > } > > > > > > > > Then .rela* in > > > > > > > > /DISCARD/ : { > > > > *(*.EMB.apuinfo) > > > > *(.glink .iplt .plt .rela* .comment) > > > > *(.gnu.version*) > > > > *(.gnu.attributes) > > > > *(.eh_frame) > > > > } > > > > > > > > is honored. Can someone from POWERPC comment on it? > > > > > > Hmm OK. I'm not really a toolchain person. > > > > > > The comment on DISCARDS says: > > > > > > * Some archs want to discard exit text/data at runtime rather than > > > * link time due to cross-section references such as alt instructions, > > > * bug table, eh_frame, etc. DISCARDS must be the last of output > > > * section definitions so that such archs put those in earlier section > > > * definitions. > > > */ > > > > > > But I guess you're changing those semantics in your series. > > > > > > This seems to fix the warning for me? > > > > > > diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S > > > index b4c89a1acebb..076b3e8a849d 100644 > > > --- a/arch/powerpc/kernel/vmlinux.lds.S > > > +++ b/arch/powerpc/kernel/vmlinux.lds.S > > > @@ -365,9 +365,12 @@ SECTIONS > > > DISCARDS > > > /DISCARD/ : { > > > *(*.EMB.apuinfo) > > > - *(.glink .iplt .plt .rela* .comment) > > > + *(.glink .iplt .plt .comment) > > > *(.gnu.version*) > > > *(.gnu.attributes) > > > *(.eh_frame) > > > +#ifndef CONFIG_RELOCATABLE > > > + *(.rela*) > > > +#endif > > > } > > > } > > > > > > > > > cheers > > > > This looks correct me. > > > > Reviewed-by: H.J. Lu <hjl.tools@gmail.com> > > > > Thanks. > > > > Has this been merged into any branch yet? I just checked the tip tree and did > not see it. > FYI, my patches have been queued on x86/build branch. Could someone from PPC community add this patch to PPC kernel to avoid upcoming PPC kernel build failure? Thanks. -- H.J.
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --] Hi H.J., On Sun, 29 Mar 2020 20:53:42 -0700 "H.J. Lu" <hjl.tools@gmail.com> wrote: > > Please see my enclosing email. Is anyone from PPC community reading emails? What you really need is an Ack from the PowerPC people for the fix you suggested and then tha fix should go in the same series that is now causing the failure (preferably before the problematic (for PowerPC) patch. For reference, the change is (white space damaged): diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S index b4c89a1acebb..076b3e8a849d 100644 --- a/arch/powerpc/kernel/vmlinux.lds.S +++ b/arch/powerpc/kernel/vmlinux.lds.S @@ -365,9 +365,12 @@ SECTIONS DISCARDS /DISCARD/ : { *(*.EMB.apuinfo) - *(.glink .iplt .plt .rela* .comment) + *(.glink .iplt .plt .comment) *(.gnu.version*) *(.gnu.attributes) *(.eh_frame) +#ifndef CONFIG_RELOCATABLE + *(.rela*) +#endif } } -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Mar 30, 2020 at 03:08:19PM +1100, Stephen Rothwell wrote:
> What you really need is an Ack from the PowerPC people for the fix you
> suggested and then tha fix should go in the same series that is now
> causing the failure (preferably before the problematic (for PowerPC)
> patch.
I'll zap this commit from the tip lineup. There's always another merge
window.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
Borislav Petkov <bp@suse.de> writes:
> On Mon, Mar 30, 2020 at 03:08:19PM +1100, Stephen Rothwell wrote:
>> What you really need is an Ack from the PowerPC people for the fix you
>> suggested and then tha fix should go in the same series that is now
>> causing the failure (preferably before the problematic (for PowerPC)
>> patch.
>
> I'll zap this commit from the tip lineup. There's always another merge
> window.
Or just squash the hunk Stephen posted into the commit, which is what I
thought would happen to begin with.
You can have my ack for it:
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
On Mon, Mar 30, 2020 at 07:04:16PM +1100, Michael Ellerman wrote:
> Or just squash the hunk Stephen posted into the commit, which is what I
> thought would happen to begin with.
>
> You can have my ack for it:
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Thanks but considering how this is not really urgent stuff and it can
take its time and get some wider testing before getting upstream, I'd
prefer to delay it.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Mon, Mar 30, 2020 at 1:17 AM Borislav Petkov <bp@suse.de> wrote:
>
> On Mon, Mar 30, 2020 at 07:04:16PM +1100, Michael Ellerman wrote:
> > Or just squash the hunk Stephen posted into the commit, which is what I
> > thought would happen to begin with.
> >
> > You can have my ack for it:
> >
> > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
>
> Thanks but considering how this is not really urgent stuff and it can
> take its time and get some wider testing before getting upstream, I'd
> prefer to delay it.
Skip my commit will also delay other commits since they depend on my
commit.
--
H.J.
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --] Hi all, On Thu, 26 Mar 2020 13:52:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/power/reset/sc27xx-poweroff.c: In function 'sc27xx_poweroff_shutdown': > drivers/power/reset/sc27xx-poweroff.c:38:4: error: implicit declaration of function 'cpu_down' [-Werror=implicit-function-declaration] > 38 | cpu_down(cpu); > | ^~~~~~~~ > > Caused by commit > > 33c3736ec888 ("cpu/hotplug: Hide cpu_up/down()") > > interacting with commit > > 274afbc3ad33 ("power: reset: sc27xx: Change to use cpu_down()") > > from the battery tree. > > I have added the following merge fix patch: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Thu, 26 Mar 2020 13:42:00 +1100 > Subject: [PATCH] power: reset: sc27xx: use remove_cpu instead of cpu_down > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > drivers/power/reset/sc27xx-poweroff.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c > index 69863074daf6..90287c31992c 100644 > --- a/drivers/power/reset/sc27xx-poweroff.c > +++ b/drivers/power/reset/sc27xx-poweroff.c > @@ -35,7 +35,7 @@ static void sc27xx_poweroff_shutdown(void) > > for_each_online_cpu(cpu) { > if (cpu != smp_processor_id()) > - cpu_down(cpu); > + remove_cpu(cpu); > } > #endif > } > -- > 2.25.0 This fixup is now needed when the battery tree is merged into Linus' tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Apr 1, 2020 at 9:14 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Thu, 26 Mar 2020 13:52:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/power/reset/sc27xx-poweroff.c: In function 'sc27xx_poweroff_shutdown':
> > drivers/power/reset/sc27xx-poweroff.c:38:4: error: implicit declaration of function 'cpu_down' [-Werror=implicit-function-declaration]
> > 38 | cpu_down(cpu);
> > | ^~~~~~~~
> >
> > Caused by commit
> >
> > 33c3736ec888 ("cpu/hotplug: Hide cpu_up/down()")
> >
> > interacting with commit
> >
> > 274afbc3ad33 ("power: reset: sc27xx: Change to use cpu_down()")
> >
> > from the battery tree.
> >
> > I have added the following merge fix patch:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 26 Mar 2020 13:42:00 +1100
> > Subject: [PATCH] power: reset: sc27xx: use remove_cpu instead of cpu_down
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/power/reset/sc27xx-poweroff.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c
> > index 69863074daf6..90287c31992c 100644
> > --- a/drivers/power/reset/sc27xx-poweroff.c
> > +++ b/drivers/power/reset/sc27xx-poweroff.c
> > @@ -35,7 +35,7 @@ static void sc27xx_poweroff_shutdown(void)
> >
> > for_each_online_cpu(cpu) {
> > if (cpu != smp_processor_id())
> > - cpu_down(cpu);
> > + remove_cpu(cpu);
> > }
> > #endif
> > }
> > --
> > 2.25.0
>
> This fixup is now needed when the battery tree is merged into Linus' tree.
Thanks Stephen.
Sebastian, could you pick up this patch to avoid the compiling issue? Thanks.
--
Baolin Wang
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --] Hi, On Fri, Apr 03, 2020 at 04:15:11PM +0800, Baolin Wang wrote: > On Wed, Apr 1, 2020 at 9:14 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 26 Mar 2020 13:52:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > Hi all, > > > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > > failed like this: > > > > > > drivers/power/reset/sc27xx-poweroff.c: In function 'sc27xx_poweroff_shutdown': > > > drivers/power/reset/sc27xx-poweroff.c:38:4: error: implicit declaration of function 'cpu_down' [-Werror=implicit-function-declaration] > > > 38 | cpu_down(cpu); > > > | ^~~~~~~~ > > > > > > Caused by commit > > > > > > 33c3736ec888 ("cpu/hotplug: Hide cpu_up/down()") > > > > > > interacting with commit > > > > > > 274afbc3ad33 ("power: reset: sc27xx: Change to use cpu_down()") > > > > > > from the battery tree. > > > > > > I have added the following merge fix patch: > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > Date: Thu, 26 Mar 2020 13:42:00 +1100 > > > Subject: [PATCH] power: reset: sc27xx: use remove_cpu instead of cpu_down > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > > --- > > > drivers/power/reset/sc27xx-poweroff.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/power/reset/sc27xx-poweroff.c b/drivers/power/reset/sc27xx-poweroff.c > > > index 69863074daf6..90287c31992c 100644 > > > --- a/drivers/power/reset/sc27xx-poweroff.c > > > +++ b/drivers/power/reset/sc27xx-poweroff.c > > > @@ -35,7 +35,7 @@ static void sc27xx_poweroff_shutdown(void) > > > > > > for_each_online_cpu(cpu) { > > > if (cpu != smp_processor_id()) > > > - cpu_down(cpu); > > > + remove_cpu(cpu); > > > } > > > #endif > > > } > > > -- > > > 2.25.0 > > > > This fixup is now needed when the battery tree is merged into Linus' tree. Thanks for the reminder. > Thanks Stephen. > > Sebastian, could you pick up this patch to avoid the compiling issue? Thanks. I will point Linus to this patch when I send my pull request. -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --] 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 756 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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-elver@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
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --] Hi Will, On Thu, 21 May 2020 18:35:22 +0100 Will Deacon <will@kernel.org> 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-elver@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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --] Hi all, On Fri, 22 May 2020 17:17:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 21 May 2020 18:35:22 +0100 Will Deacon <will@kernel.org> 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-elver@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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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 <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 21 May 2020 18:35:22 +0100 Will Deacon <will@kernel.org> 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-elver@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
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
Borislav Petkov <bp@alien8.de> 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
On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner wrote:
> Borislav Petkov <bp@alien8.de> 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
"Paul E. McKenney" <paulmck@kernel.org> 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
On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> "Paul E. McKenney" <paulmck@kernel.org> 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
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" <paulmck@kernel.org> 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
On Mon, 25 May 2020 at 02:37, Paul E. McKenney <paulmck@kernel.org> 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" <paulmck@kernel.org> 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
On Mon, May 25, 2020 at 10:20:29AM +0200, Marco Elver wrote:
> On Mon, 25 May 2020 at 02:37, Paul E. McKenney <paulmck@kernel.org> 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" <paulmck@kernel.org> 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
[-- Attachment #1: Type: text/plain, Size: 708 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
+ 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 <bp@suse.de> 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 <sfr@canb.auug.org.au> Signed-off-by: Borislav Petkov <bp@suse.de> --- 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_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 0x00000123 +#define RNGDS_MITG_DIS BIT(0) + #define MSR_IA32_SYSENTER_CS 0x00000174 #define MSR_IA32_SYSENTER_ESP 0x00000175 #define MSR_IA32_SYSENTER_EIP 0x00000176 @@ -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_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 MSR_F15H_PERF_CTL1 (MSR_F15H_PERF_CTL + 2) -- 2.21.0 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[-- Attachment #1: Type: text/plain, Size: 377 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 5324 bytes --] Hi Borislav, On Sun, 21 Jun 2020 12:53:50 +0200 Borislav Petkov <bp@alien8.de> 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 <bp@suse.de> > 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 <sfr@canb.auug.org.au> > Signed-off-by: Borislav Petkov <bp@suse.de> > --- > 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_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 0x00000123 > +#define RNGDS_MITG_DIS BIT(0) > + > #define MSR_IA32_SYSENTER_CS 0x00000174 > #define MSR_IA32_SYSENTER_ESP 0x00000175 > #define MSR_IA32_SYSENTER_EIP 0x00000176 > @@ -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_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 MSR_F15H_PERF_CTL1 (MSR_F15H_PERF_CTL + 2) I applied that patch to the tip tree merge today. Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # build tested -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 522 bytes --] Hi all, On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 657 bytes --] Hi all, On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 795 bytes --] Hi all, On Tue, 7 Jul 2020 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > > failed like this: > > > > > > 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1281 bytes --] Hi all, On Tue, 14 Jul 2020 13:50:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Tue, 7 Jul 2020 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > > > failed like this: > > > > > > > > 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> 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
[-- Attachment #1: Type: text/plain, Size: 679 bytes --] Hi Ingo, On Fri, 31 Jul 2020 11:57:35 +0200 Ingo Molnar <mingo@kernel.org> 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 456 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --] 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 <sfr@canb.auug.org.au> Date: Thu, 3 Sep 2020 12:31:13 +1000 Subject: [PATCH] merge fix for compiler.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- 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) /* &a[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 <asm/rwonce.h> /* -- 2.28.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
>
> 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 <sfr@canb.auug.org.au>
> 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
[-- Attachment #1: Type: text/plain, Size: 202 bytes --] Hi Ingo, On Thu, 3 Sep 2020 05:51:08 +0200 Ingo Molnar <mingo@kernel.org> wrote: > > I've merged the old commit by mistake - it's removed now. Ah, OK, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 578 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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 = &STATIC_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)
[-- Attachment #1: Type: text/plain, Size: 2901 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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(-) -- ⣿⣿⣿⣿⢋⡀⣀⠹⣿⣿⣿⣿ ⣿⣿⣿⣿⠠⣶⡦⠀⣿⣿⣿⣿ ⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿ ⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿ ⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿ ⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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_SLD 18 /* 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --] 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> 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
[-- Attachment #1: Type: text/plain, Size: 625 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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
[-- Attachment #1: Type: text/plain, Size: 1333 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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.
[-- Attachment #1: Type: text/plain, Size: 238 bytes --] Hi Peter, On Wed, 3 Mar 2021 10:44:32 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > Damn, sorry about that. I've rebased tip/sched/core and all should be > well now. Excellent, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 555 bytes --] 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 <asm/inat.h> /*__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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
+ 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 <asm/inat.h> /*__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 <bp@suse.de> 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 <asm/inat.h> /*__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 <irogers@google.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> NOT-Signed-off-by: Borislav Petkov <bp@suse.de> --- 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 <string.h> #endif -#include <asm/inat.h> /*__ignore_sync_check__ */ -#include <asm/insn.h> /* __ignore_sync_check__ */ +#include "../include/asm/inat.h" /* __ignore_sync_check__ */ +#include "../include/asm/insn.h" /* __ignore_sync_check__ */ #include <linux/errno.h> #include <linux/kconfig.h> -- 2.29.2 -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Wed, Mar 17, 2021 at 3:54 AM Borislav Petkov <bp@suse.de> 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 <asm/inat.h> /*__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 <asm/emulate_prefix.h> 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 <string.h> #endif -#include <asm/inat.h> /*__ignore_sync_check__ */ -#include <asm/insn.h> /* __ignore_sync_check__ */ +#include "../include/asm/inat.h" /*__ignore_sync_check__ */ +#include "../include/asm/insn.h" /* __ignore_sync_check__ */ #include <linux/errno.h> #include <linux/kconfig.h> -#include <asm/emulate_prefix.h> /* __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 <bp@suse.de> > 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 <asm/inat.h> /*__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 <irogers@google.com> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> > NOT-Signed-off-by: Borislav Petkov <bp@suse.de> > --- > 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 <string.h> > #endif > -#include <asm/inat.h> /*__ignore_sync_check__ */ > -#include <asm/insn.h> /* __ignore_sync_check__ */ > +#include "../include/asm/inat.h" /* __ignore_sync_check__ */ > +#include "../include/asm/insn.h" /* __ignore_sync_check__ */ > > #include <linux/errno.h> > #include <linux/kconfig.h> > -- > 2.29.2 > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Wed, Mar 17, 2021 at 09:22:15AM -0700, Ian Rogers wrote: > The <asm/emulate_prefix.h> 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 <bp@suse.de> 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 <asm/inat.h> /*__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 <irogers@google.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Ian Rogers <irogers@google.com> --- 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 <string.h> #endif -#include <asm/inat.h> /*__ignore_sync_check__ */ -#include <asm/insn.h> /* __ignore_sync_check__ */ +#include "../include/asm/inat.h" /* __ignore_sync_check__ */ +#include "../include/asm/insn.h" /* __ignore_sync_check__ */ #include <linux/errno.h> #include <linux/kconfig.h> -#include <asm/emulate_prefix.h> /* __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
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --] Hi Borislav, On Wed, 17 Mar 2021 19:02:36 +0100 Borislav Petkov <bp@suse.de> wrote: > > On Wed, Mar 17, 2021 at 09:22:15AM -0700, Ian Rogers wrote: > > The <asm/emulate_prefix.h> 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 <bp@suse.de> > 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 <asm/inat.h> /*__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 <irogers@google.com> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> > Signed-off-by: Borislav Petkov <bp@suse.de> > Tested-by: Ian Rogers <irogers@google.com> > --- > 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 <string.h> > #endif > -#include <asm/inat.h> /*__ignore_sync_check__ */ > -#include <asm/insn.h> /* __ignore_sync_check__ */ > +#include "../include/asm/inat.h" /* __ignore_sync_check__ */ > +#include "../include/asm/insn.h" /* __ignore_sync_check__ */ > > #include <linux/errno.h> > #include <linux/kconfig.h> > > -#include <asm/emulate_prefix.h> /* __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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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
* Borislav Petkov <bp@suse.de> 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
Hi Ingo,
On Wed, 17 Mar 2021 21:04:08 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Borislav Petkov <bp@suse.de> 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
[-- Attachment #1: Type: text/plain, Size: 2047 bytes --] 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(&prog, 5) for BPF_TRAMP_F_CALL_ORIG") from the net tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 22 Mar 2021 14:30:37 +1100 Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of emit_nops(&prog, 5) for BPF_TRAMP_F_CALL_ORIG" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- 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(&prog, 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
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(&prog, 5) for BPF_TRAMP_F_CALL_ORIG")
>
> from the net tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 22 Mar 2021 14:30:37 +1100
> Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
> emit_nops(&prog, 5) for BPF_TRAMP_F_CALL_ORIG"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> 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(&prog, 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
On Mon, Mar 22, 2021 at 4:39 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/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(&prog, 5) for BPF_TRAMP_F_CALL_ORIG") > > from the net tree. > > I have applied the following merge fix patch. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 22 Mar 2021 14:30:37 +1100 > Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of > emit_nops(&prog, 5) for BPF_TRAMP_F_CALL_ORIG" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> I had the same issue yesterday, when I had... <tip.git#x86/cpu> + <net.git#master> ...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&id=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(&prog, 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
On Mon, Mar 22, 2021 at 10:02 AM Borislav Petkov <bp@suse.de> 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(&prog, 5) for BPF_TRAMP_F_CALL_ORIG") > > > > from the net tree. > > > > I have applied the following merge fix patch. > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Mon, 22 Mar 2021 14:30:37 +1100 > > Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of > > emit_nops(&prog, 5) for BPF_TRAMP_F_CALL_ORIG" > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > --- > > 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(&prog, 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(&prog, 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? <tip.git#x86/cpu>? Thanks. - Sedat - [1] https://git.kernel.org/linus/b9082970478009b778aa9b22d5561eef35b53b63
On Fri, Mar 26, 2021 at 09:57:43AM +0100, Sedat Dilek wrote:
> The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of
> emit_nops(&prog, 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?
> <tip.git#x86/cpu>?
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
On Fri, Mar 26, 2021 at 2:11 PM Borislav Petkov <bp@suse.de> 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(&prog, 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?
> > <tip.git#x86/cpu>?
>
> 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(&prog, 5) for
BPF_TRAMP_F_CALL_ORIG"
Feel free to add my:
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc3 (x86-64)
- Sedat -
[-- Attachment #1: Type: text/plain, Size: 490 bytes --] Hi Sedat, On Sat, 27 Mar 2021 12:50:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 610 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from tools/arch/x86/include/asm/nops.h:5, from arch/x86/decode.c:15: tools/arch/x86/include/asm/asm.h:185:24: error: invalid register name for 'current_stack_pointer' 185 | register unsigned long current_stack_pointer asm(_ASM_SP); | ^~~~~~~~~~~~~~~~~~~~~ Caused by commit eef23e72b78b ("x86/asm: Use _ASM_BYTES() in <asm/nops.h>") I have used the tip tree from next-20210512 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from tools/arch/x86/include/asm/nops.h:5, > from arch/x86/decode.c:15: > tools/arch/x86/include/asm/asm.h:185:24: error: invalid register name for 'current_stack_pointer' > 185 | register unsigned long current_stack_pointer asm(_ASM_SP); > | ^~~~~~~~~~~~~~~~~~~~~ > > Caused by commit > > eef23e72b78b ("x86/asm: Use _ASM_BYTES() in <asm/nops.h>") > > I have used the tip tree from next-20210512 for today. Hm, this must be some cross-build artifact or toolchain version dependency - as plain native build of x86-64 allmodconfig builds just fine: CC arch/x86/decode.o LD arch/x86/objtool-in.o I tried with gcc-8, but that didn't trigger it. I suppose the workaround below would make it build - but that's not a real solution. hpa, any ideas? Thanks, Ingo diff --git a/tools/arch/x86/include/asm/asm.h b/tools/arch/x86/include/asm/asm.h index 507a37a46027..ada5482c024a 100644 --- a/tools/arch/x86/include/asm/asm.h +++ b/tools/arch/x86/include/asm/asm.h @@ -176,14 +176,6 @@ /* For C file, we already have NOKPROBE_SYMBOL macro */ -/* - * This output constraint should be used for any inline asm which has a "call" - * instruction. Otherwise the asm may be inserted before the frame pointer - * gets set up by the containing function. If you forget to do this, objtool - * may print a "call without frame pointer save/setup" warning. - */ -register unsigned long current_stack_pointer asm(_ASM_SP); -#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer) #endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_ASM_H */
Needed some head scratching, but then...
It makes sense for the cross-build: it's building for the host, and a non-x86 machine isn't doing to have a register named "%rsp".
So this needs to be protected from non-kernel use either via __KERNEL__ or by factoring the basic macros out into a separate file.
Incidentally, we seem to have three categories of include files now: kernel-only, uapi, and "tools api". Perhaps we need such a "tapi" directory instead of copying things around... the infrastructure for uapi with make headers_install etc ought to be generalizable.
On May 13, 2021 3:51:47 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
>
>* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>> failed like this:
>>
>> In file included from tools/arch/x86/include/asm/nops.h:5,
>> from arch/x86/decode.c:15:
>> tools/arch/x86/include/asm/asm.h:185:24: error: invalid register name
>for 'current_stack_pointer'
>> 185 | register unsigned long current_stack_pointer asm(_ASM_SP);
>> | ^~~~~~~~~~~~~~~~~~~~~
>>
>> Caused by commit
>>
>> eef23e72b78b ("x86/asm: Use _ASM_BYTES() in <asm/nops.h>")
>>
>> I have used the tip tree from next-20210512 for today.
>
>Hm, this must be some cross-build artifact or toolchain version
>dependency
>- as plain native build of x86-64 allmodconfig builds just fine:
>
> CC arch/x86/decode.o
> LD arch/x86/objtool-in.o
>
>I tried with gcc-8, but that didn't trigger it.
>
>I suppose the workaround below would make it build - but that's not a
>real
>solution.
>
>hpa, any ideas?
>
>Thanks,
>
> Ingo
>
>diff --git a/tools/arch/x86/include/asm/asm.h
>b/tools/arch/x86/include/asm/asm.h
>index 507a37a46027..ada5482c024a 100644
>--- a/tools/arch/x86/include/asm/asm.h
>+++ b/tools/arch/x86/include/asm/asm.h
>@@ -176,14 +176,6 @@
>
> /* For C file, we already have NOKPROBE_SYMBOL macro */
>
>-/*
>- * This output constraint should be used for any inline asm which has
>a "call"
>- * instruction. Otherwise the asm may be inserted before the frame
>pointer
>- * gets set up by the containing function. If you forget to do this,
>objtool
>- * may print a "call without frame pointer save/setup" warning.
>- */
>-register unsigned long current_stack_pointer asm(_ASM_SP);
>-#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
> #endif /* __ASSEMBLY__ */
>
> #endif /* _ASM_X86_ASM_H */
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/module.h:21, from include/kunit/test.h:15, from kernel/time/time_test.c:3: kernel/time/time_test.c:99:16: error: expected ',' or ';' before 'GPL' 99 | MODULE_LICENSE(GPL); | ^~~ include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO' 26 | = __MODULE_INFO_PREFIX __stringify(tag) "=" info | ^~~~ include/linux/module.h:229:46: note: in expansion of macro 'MODULE_INFO' 229 | #define MODULE_LICENSE(_license) MODULE_FILE MODULE_INFO(license, _license) | ^~~~~~~~~~~ kernel/time/time_test.c:99:1: note: in expansion of macro 'MODULE_LICENSE' 99 | MODULE_LICENSE(GPL); | ^~~~~~~~~~~~~~ Caused by commit 34c7342ac1b4 ("time/kunit: Add missing MODULE_LICENSE()") I have used the tip tree from next-20210625 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/module.h:21,
> from include/kunit/test.h:15,
> from kernel/time/time_test.c:3:
> kernel/time/time_test.c:99:16: error: expected ',' or ';' before 'GPL'
> 99 | MODULE_LICENSE(GPL);
> | ^~~
> include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO'
> 26 | = __MODULE_INFO_PREFIX __stringify(tag) "=" info
> | ^~~~
> include/linux/module.h:229:46: note: in expansion of macro 'MODULE_INFO'
> 229 | #define MODULE_LICENSE(_license) MODULE_FILE MODULE_INFO(license, _license)
> | ^~~~~~~~~~~
> kernel/time/time_test.c:99:1: note: in expansion of macro 'MODULE_LICENSE'
> 99 | MODULE_LICENSE(GPL);
> | ^~~~~~~~~~~~~~
>
> Caused by commit
>
> 34c7342ac1b4 ("time/kunit: Add missing MODULE_LICENSE()")
Yeah, that should be "GPL". I amended the commit, so this bug should be
gone by tomorrow.
Thanks,
Ingo
[-- Attachment #1: Type: text/plain, Size: 1785 bytes --] 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/../../../arch/x86/lib/insn.c:16, from util/intel-pt-decoder/intel-pt-insn-decoder.c:15: util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix': tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed] 10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ | ^ tools/include/../include/asm-generic/unaligned.h:19:28: note: in expansion of macro '__get_unaligned_t' 19 | #define get_unaligned(ptr) __get_unaligned_t(typeof(*(ptr)), (ptr)) | ^~~~~~~~~~~~~~~~~ util/intel-pt-decoder/../../../arch/x86/lib/insn.c:44:11: note: in expansion of macro 'get_unaligned' 44 | ({ t r = get_unaligned((t *)(insn)->next_byte + n); leXX_to_cpu(t, r); }) | ^~~~~~~~~~~~~ util/intel-pt-decoder/../../../arch/x86/lib/insn.c:50:61: note: in expansion of macro '__peek_nbyte_next' 50 | ({ 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:91:7: note: in expansion of macro 'peek_nbyte_next' 91 | if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i]) | ^~~~~~~~~~~~~~~ and many similar ... Caused by commit a1be25a30cf6 ("x86/insn: Use get_unaligned() instead of memcpy()") "native" here is ppc64le. gcc (Debian 10.3.0-11) 10.3.0 I have used the tip tree from next-20211005 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
+ acme. On Wed, Oct 06, 2021 at 01:58:26PM +1100, Stephen Rothwell wrote: > After merging the tip tree, today's linux-next build (native perf) > failed like this: > > In file included from util/intel-pt-decoder/../../../arch/x86/lib/insn.c:16, > from util/intel-pt-decoder/intel-pt-insn-decoder.c:15: > util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix': > tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed] > 10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ Thanks for the report - luckily, the patch is the topmost one on the branch so I can simply edit it. Here's the new version, you can simply apply the last hunk on your tree only to verify that it fixes it but it should as the hw arch should not matter - it explodes because perf tool builds with -Werror and I can trigger it too. I'll redo tip/master once you confirm. Thx. --- From: Borislav Petkov <bp@suse.de> Date: Wed, 29 Sep 2021 16:37:53 +0200 Subject: [PATCH] x86/insn: Use get_unaligned() instead of memcpy() Use get_unaligned() instead of memcpy() to access potentially unaligned memory, which, when accessed through a pointer, leads to undefined behavior. get_unaligned() describes much better what is happening there anyway even if memcpy() does the job. In addition, since perf tool builds with -Werror, it would fire with: util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix': tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed] 10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ because -Werror=packed would complain if the packed attribute would have no effect on the layout of the structure. In this case, that is intentional so disable the warning only for that compilation unit. That part is Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> No functional changes. Fixes: 5ba1071f7554 ("x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Link: https://lkml.kernel.org/r/YVSsIkj9Z29TyUjE@zn.tnic --- arch/x86/lib/insn.c | 5 +++-- tools/arch/x86/lib/insn.c | 5 +++-- tools/include/asm-generic/unaligned.h | 23 +++++++++++++++++++++++ tools/perf/util/intel-pt-decoder/Build | 2 ++ 4 files changed, 31 insertions(+), 4 deletions(-) create mode 100644 tools/include/asm-generic/unaligned.h diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c index c565def611e2..55e371cc69fd 100644 --- a/arch/x86/lib/insn.c +++ b/arch/x86/lib/insn.c @@ -13,6 +13,7 @@ #endif #include <asm/inat.h> /*__ignore_sync_check__ */ #include <asm/insn.h> /* __ignore_sync_check__ */ +#include <asm/unaligned.h> /* __ignore_sync_check__ */ #include <linux/errno.h> #include <linux/kconfig.h> @@ -37,10 +38,10 @@ ((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr) #define __get_next(t, insn) \ - ({ t r; memcpy(&r, insn->next_byte, sizeof(t)); insn->next_byte += sizeof(t); leXX_to_cpu(t, r); }) + ({ t r = get_unaligned((t *)(insn)->next_byte); (insn)->next_byte += sizeof(t); leXX_to_cpu(t, r); }) #define __peek_nbyte_next(t, insn, n) \ - ({ t r; memcpy(&r, (insn)->next_byte + n, sizeof(t)); leXX_to_cpu(t, r); }) + ({ t r = get_unaligned((t *)(insn)->next_byte + n); leXX_to_cpu(t, r); }) #define get_next(t, insn) \ ({ if (unlikely(!validate_next(t, insn, 0))) goto err_out; __get_next(t, insn); }) diff --git a/tools/arch/x86/lib/insn.c b/tools/arch/x86/lib/insn.c index 797699462cd8..8fd63a067308 100644 --- a/tools/arch/x86/lib/insn.c +++ b/tools/arch/x86/lib/insn.c @@ -13,6 +13,7 @@ #endif #include "../include/asm/inat.h" /* __ignore_sync_check__ */ #include "../include/asm/insn.h" /* __ignore_sync_check__ */ +#include "../include/asm-generic/unaligned.h" /* __ignore_sync_check__ */ #include <linux/errno.h> #include <linux/kconfig.h> @@ -37,10 +38,10 @@ ((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr) #define __get_next(t, insn) \ - ({ t r; memcpy(&r, insn->next_byte, sizeof(t)); insn->next_byte += sizeof(t); leXX_to_cpu(t, r); }) + ({ t r = get_unaligned((t *)(insn)->next_byte); (insn)->next_byte += sizeof(t); leXX_to_cpu(t, r); }) #define __peek_nbyte_next(t, insn, n) \ - ({ t r; memcpy(&r, (insn)->next_byte + n, sizeof(t)); leXX_to_cpu(t, r); }) + ({ t r = get_unaligned((t *)(insn)->next_byte + n); leXX_to_cpu(t, r); }) #define get_next(t, insn) \ ({ if (unlikely(!validate_next(t, insn, 0))) goto err_out; __get_next(t, insn); }) diff --git a/tools/include/asm-generic/unaligned.h b/tools/include/asm-generic/unaligned.h new file mode 100644 index 000000000000..47387c607035 --- /dev/null +++ b/tools/include/asm-generic/unaligned.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copied from the kernel sources to tools/perf/: + */ + +#ifndef __TOOLS_LINUX_ASM_GENERIC_UNALIGNED_H +#define __TOOLS_LINUX_ASM_GENERIC_UNALIGNED_H + +#define __get_unaligned_t(type, ptr) ({ \ + const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ + __pptr->x; \ +}) + +#define __put_unaligned_t(type, val, ptr) do { \ + struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ + __pptr->x = (val); \ +} while (0) + +#define get_unaligned(ptr) __get_unaligned_t(typeof(*(ptr)), (ptr)) +#define put_unaligned(val, ptr) __put_unaligned_t(typeof(*(ptr)), (val), (ptr)) + +#endif /* __TOOLS_LINUX_ASM_GENERIC_UNALIGNED_H */ + diff --git a/tools/perf/util/intel-pt-decoder/Build b/tools/perf/util/intel-pt-decoder/Build index bc629359826f..b41c2e9c6f88 100644 --- a/tools/perf/util/intel-pt-decoder/Build +++ b/tools/perf/util/intel-pt-decoder/Build @@ -18,3 +18,5 @@ CFLAGS_intel-pt-insn-decoder.o += -I$(OUTPUT)util/intel-pt-decoder ifeq ($(CC_NO_CLANG), 1) CFLAGS_intel-pt-insn-decoder.o += -Wno-override-init endif + +CFLAGS_intel-pt-insn-decoder.o += -Wno-packed -- 2.29.2 -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --] Hi Borislav, On Wed, 6 Oct 2021 11:31:00 +0200 Borislav Petkov <bp@suse.de> wrote: > > + acme. > > On Wed, Oct 06, 2021 at 01:58:26PM +1100, Stephen Rothwell wrote: > > After merging the tip tree, today's linux-next build (native perf) > > failed like this: > > > > In file included from util/intel-pt-decoder/../../../arch/x86/lib/insn.c:16, > > from util/intel-pt-decoder/intel-pt-insn-decoder.c:15: > > util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix': > > tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed] > > 10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ > > Thanks for the report - luckily, the patch is the topmost one on the > branch so I can simply edit it. > > Here's the new version, you can simply apply the last hunk on your tree > only to verify that it fixes it but it should as the hw arch should not > matter - it explodes because perf tool builds with -Werror and I can > trigger it too. > > I'll redo tip/master once you confirm. Works for me, thanks. Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # ppc64le compile -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen,
On Wed, Oct 06, 2021 at 08:54:44PM +1100, Stephen Rothwell wrote:
> Works for me, thanks.
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # ppc64le compile
Thx!
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 788 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allnoconfig) failed like this: arch/x86/kernel/process.c: In function '__get_wchan': arch/x86/kernel/process.c:950:2: error: implicit declaration of function 'stack_trace_save_tsk' [-Werror=implicit-function-declaration] 950 | stack_trace_save_tsk(p, &entry, 1, 0); | ^~~~~~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors Caused by commit bc9bbb81730e ("x86: Fix get_wchan() to support the ORC unwinder") stack_trace_save_tsk() requires CONFIG_STACKTRACE which is not set for this build. I have reverted that commit, and commit 42a20f86dc19 ("sched: Add wrapper for get_wchan() to keep task blocked") which follows it, for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 10/18/21 2:23 PM, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allnoconfig) > failed like this: > > arch/x86/kernel/process.c: In function '__get_wchan': > arch/x86/kernel/process.c:950:2: error: implicit declaration of function 'stack_trace_save_tsk' [-Werror=implicit-function-declaration] > 950 | stack_trace_save_tsk(p, &entry, 1, 0); > | ^~~~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors > > Caused by commit > > bc9bbb81730e ("x86: Fix get_wchan() to support the ORC unwinder") > > stack_trace_save_tsk() requires CONFIG_STACKTRACE which is not set for > this build. Maybe get_wchan() can be updated to: unsigned long get_wchan(struct task_struct *p) { #ifdef CONFIG_STACKTRACE unsigned long entry = 0; stack_trace_save_tsk(p, &entry, 1, 0); return entry; #else /* CONFIG_STACKTRACE */ return 0; #endif } Thanks, Qi > > I have reverted that commit, and commit > > 42a20f86dc19 ("sched: Add wrapper for get_wchan() to keep task blocked") > > which follows it, for today. >
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/kernel/fpu/core.c: In function 'fpu_alloc_guest_fpstate': arch/x86/kernel/fpu/core.c:187:12: error: implicit declaration of function 'vzalloc'; did you mean 'kzalloc'? [-Werror=implicit-function-declaration] 187 | fpstate = vzalloc(size); | ^~~~~~~ | kzalloc arch/x86/kernel/fpu/core.c:187:10: error: assignment to 'struct fpstate *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 187 | fpstate = vzalloc(size); | ^ arch/x86/kernel/fpu/core.c: In function 'fpu_free_guest_fpstate': arch/x86/kernel/fpu/core.c:212:2: error: implicit declaration of function 'vfree'; did you mean 'kfree'? [-Werror=implicit-function-declaration] 212 | vfree(fps); | ^~~~~ | kfree cc1: all warnings being treated as errors Caused by commit 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") I have applied the following patch for today (because it was quicker than using the tip tree from next-20211022). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 25 Oct 2021 15:04:13 +1100 Subject: [PATCH] x86/fpu: include vmalloc.h for vzalloc etc Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/x86/kernel/fpu/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 9c475e2efd4d..c55013fc82ab 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -16,6 +16,7 @@ #include <linux/hardirq.h> #include <linux/pkeys.h> +#include <linux/vmalloc.h> #include "context.h" #include "internal.h" -- 2.33.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On Mon, Oct 25, 2021 at 03:11:44PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/kernel/fpu/core.c: In function 'fpu_alloc_guest_fpstate': > arch/x86/kernel/fpu/core.c:187:12: error: implicit declaration of function 'vzalloc'; did you mean 'kzalloc'? [-Werror=implicit-function-declaration] > 187 | fpstate = vzalloc(size); > | ^~~~~~~ > | kzalloc > arch/x86/kernel/fpu/core.c:187:10: error: assignment to 'struct fpstate *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] > 187 | fpstate = vzalloc(size); > | ^ > arch/x86/kernel/fpu/core.c: In function 'fpu_free_guest_fpstate': > arch/x86/kernel/fpu/core.c:212:2: error: implicit declaration of function 'vfree'; did you mean 'kfree'? [-Werror=implicit-function-declaration] > 212 | vfree(fps); > | ^~~~~ > | kfree > cc1: all warnings being treated as errors > > Caused by commit > > 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") > > I have applied the following patch for today (because it was quicker > than using the tip tree from next-20211022). I cannot reproduce here. It could be uncovered by some stuff you merge before tip/auto-latest or so. > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 25 Oct 2021 15:04:13 +1100 > Subject: [PATCH] x86/fpu: include vmalloc.h for vzalloc etc > > Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/kernel/fpu/core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > index 9c475e2efd4d..c55013fc82ab 100644 > --- a/arch/x86/kernel/fpu/core.c > +++ b/arch/x86/kernel/fpu/core.c > @@ -16,6 +16,7 @@ > > #include <linux/hardirq.h> > #include <linux/pkeys.h> > +#include <linux/vmalloc.h> > > #include "context.h" > #include "internal.h" > -- I'm thinking I could simply fold in your change into 69f6ed1d14c6 ... Thx. -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --] Hi Borislav, On Mon, 25 Oct 2021 09:42:12 +0200 Borislav Petkov <bp@suse.de> wrote: > > I cannot reproduce here. It could be uncovered by some stuff you merge > before tip/auto-latest or so. Yeah, I fugured something like that must have happened. > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Mon, 25 Oct 2021 15:04:13 +1100 > > Subject: [PATCH] x86/fpu: include vmalloc.h for vzalloc etc > > > > Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > --- > > arch/x86/kernel/fpu/core.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > > index 9c475e2efd4d..c55013fc82ab 100644 > > --- a/arch/x86/kernel/fpu/core.c > > +++ b/arch/x86/kernel/fpu/core.c > > @@ -16,6 +16,7 @@ > > > > #include <linux/hardirq.h> > > #include <linux/pkeys.h> > > +#include <linux/vmalloc.h> > > > > #include "context.h" > > #include "internal.h" > > -- > > I'm thinking I could simply fold in your change into 69f6ed1d14c6 ... That will certainly make it more robust against people cleaning up include files. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Oct 25, 2021 at 06:58:36PM +1100, Stephen Rothwell wrote:
> That will certainly make it more robust against people cleaning up
> include files.
Ok, rebased and pushed out. You could try it now.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --] Hi all, On Mon, 25 Oct 2021 15:11:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/kernel/fpu/core.c: In function 'fpu_alloc_guest_fpstate': > arch/x86/kernel/fpu/core.c:187:12: error: implicit declaration of function 'vzalloc'; did you mean 'kzalloc'? [-Werror=implicit-function-declaration] > 187 | fpstate = vzalloc(size); > | ^~~~~~~ > | kzalloc > arch/x86/kernel/fpu/core.c:187:10: error: assignment to 'struct fpstate *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] > 187 | fpstate = vzalloc(size); > | ^ > arch/x86/kernel/fpu/core.c: In function 'fpu_free_guest_fpstate': > arch/x86/kernel/fpu/core.c:212:2: error: implicit declaration of function 'vfree'; did you mean 'kfree'? [-Werror=implicit-function-declaration] > 212 | vfree(fps); > | ^~~~~ > | kfree > cc1: all warnings being treated as errors > > Caused by commit > > 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") > > I have applied the following patch for today (because it was quicker > than using the tip tree from next-20211022). > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 25 Oct 2021 15:04:13 +1100 > Subject: [PATCH] x86/fpu: include vmalloc.h for vzalloc etc > > Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/x86/kernel/fpu/core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > index 9c475e2efd4d..c55013fc82ab 100644 > --- a/arch/x86/kernel/fpu/core.c > +++ b/arch/x86/kernel/fpu/core.c > @@ -16,6 +16,7 @@ > > #include <linux/hardirq.h> > #include <linux/pkeys.h> > +#include <linux/vmalloc.h> > > #include "context.h" > #include "internal.h" > -- > 2.33.0 This build failure has returned today :-( -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen,
On Thu, Oct 28, 2021 at 04:10:58PM +1100, Stephen Rothwell wrote:
> This build failure has returned today :-(
Sorry about that.
I had the original patch updated but then it is very possible I
fat-fingered the branch during the patch frenzy in the past days here.
Now I've applied yours because it happening a second time simply
warrants having this as a separate patch.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --] Hi all, After merging the tip tree, today's linux-next build (sparc defconfig) failed like this: In file included from arch/sparc/include/asm/futex_32.h:4:0, from arch/sparc/include/asm/futex.h:7, from kernel/futex/futex.h:12, from kernel/futex/core.c:41: kernel/futex/core.c: In function 'futex_cmpxchg_value_locked': include/asm-generic/futex.h:17:2: error: implicit declaration of function 'futex_atomic_cmpxchg_inatomic_local_generic'; did you mean 'futex_atomic_cmpxchg_inatomic_local'? [-Werror=implicit-function-declaration] futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) ^ include/asm-generic/futex.h:17:2: note: in definition of macro 'futex_atomic_cmpxchg_inatomic' futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Caused by commit 3f2bedabb62c ("futex: Ensure futex_atomic_cmpxchg_inatomic() is present") Gcc version (if it matters): sparc64-linux-gcc (Custom f51944395b6aa154) 7.3.1 20180130 I have reverted that commit for today (and the following one). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Nov 26, 2021 at 4:52 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (sparc defconfig) > failed like this: > > In file included from arch/sparc/include/asm/futex_32.h:4:0, > from arch/sparc/include/asm/futex.h:7, > from kernel/futex/futex.h:12, > from kernel/futex/core.c:41: > kernel/futex/core.c: In function 'futex_cmpxchg_value_locked': > include/asm-generic/futex.h:17:2: error: implicit declaration of function 'futex_atomic_cmpxchg_inatomic_local_generic'; did you mean 'futex_atomic_cmpxchg_inatomic_local'? [-Werror=implicit-function-declaration] > futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) > ^ > include/asm-generic/futex.h:17:2: note: in definition of macro 'futex_atomic_cmpxchg_inatomic' > futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks a lot for the report, I sent a fix now: https://lore.kernel.org/lkml/20211126095852.455492-1-arnd@kernel.org Arnd
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --] Hi all, On Fri, 26 Nov 2021 11:01:52 +0100 Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Nov 26, 2021 at 4:52 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the tip tree, today's linux-next build (sparc defconfig) > > failed like this: > > > > In file included from arch/sparc/include/asm/futex_32.h:4:0, > > from arch/sparc/include/asm/futex.h:7, > > from kernel/futex/futex.h:12, > > from kernel/futex/core.c:41: > > kernel/futex/core.c: In function 'futex_cmpxchg_value_locked': > > include/asm-generic/futex.h:17:2: error: implicit declaration of function 'futex_atomic_cmpxchg_inatomic_local_generic'; did you mean 'futex_atomic_cmpxchg_inatomic_local'? [-Werror=implicit-function-declaration] > > futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) > > ^ > > include/asm-generic/futex.h:17:2: note: in definition of macro 'futex_atomic_cmpxchg_inatomic' > > futex_atomic_cmpxchg_inatomic_local_generic(uval, uaddr, oldval, newval) > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Thanks a lot for the report, I sent a fix now: > > https://lore.kernel.org/lkml/20211126095852.455492-1-arnd@kernel.org I am still getting this failure (Arnd's fix has not been applied). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Dec 02 2021 at 09:05, Stephen Rothwell wrote:
> On Fri, 26 Nov 2021 11:01:52 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Thanks a lot for the report, I sent a fix now:
>>
>> https://lore.kernel.org/lkml/20211126095852.455492-1-arnd@kernel.org
>
> I am still getting this failure (Arnd's fix has not been applied).
It got applied, but due to tip maintainer confusion the next branch was
not updated. Will be fixed tomorrow.
Thanks,
tglx
On Wed, Dec 01 2021 at 23:17, Thomas Gleixner wrote:
> On Thu, Dec 02 2021 at 09:05, Stephen Rothwell wrote:
>> On Fri, 26 Nov 2021 11:01:52 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> Thanks a lot for the report, I sent a fix now:
>>>
>>> https://lore.kernel.org/lkml/20211126095852.455492-1-arnd@kernel.org
>>
>> I am still getting this failure (Arnd's fix has not been applied).
>
> It got applied, but due to tip maintainer confusion the next branch was
> not updated. Will be fixed tomorrow.
Actually now. So still today here :)
[-- Attachment #1: Type: text/plain, Size: 798 bytes --] Hi Thomas, On Wed, 01 Dec 2021 23:19:40 +0100 Thomas Gleixner <tglx@linutronix.de> wrote: > > On Wed, Dec 01 2021 at 23:17, Thomas Gleixner wrote: > > > On Thu, Dec 02 2021 at 09:05, Stephen Rothwell wrote: > >> On Fri, 26 Nov 2021 11:01:52 +0100 Arnd Bergmann <arnd@arndb.de> wrote: > >>> > >>> Thanks a lot for the report, I sent a fix now: > >>> > >>> https://lore.kernel.org/lkml/20211126095852.455492-1-arnd@kernel.org > >> > >> I am still getting this failure (Arnd's fix has not been applied). > > > > It got applied, but due to tip maintainer confusion the next branch was > > not updated. Will be fixed tomorrow. > > Actually now. So still today here :) Thanks, I have that now, so it will go into today's linux-next. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi all, After merging the tip tree, today's linux-next build (x86 allmodconfig) failed like this: In file included from /tmp/next/build/drivers/gpu/drm/i915/intel_device_info.h:32, from /tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11, from /tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11: /tmp/next/build/drivers/gpu/drm/i915/display/intel_display.h:643:39: error: 'struct pci_dev' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 643 | bool intel_modeset_probe_defer(struct pci_dev *pdev); | ^~~~~~~ cc1: all warnings being treated as errors I didn't investigate too closely exactly which commit caused this and fixed it up as below: diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h index 4b688a9727b39..377790393a855 100644 --- a/drivers/gpu/drm/i915/display/intel_display.h +++ b/drivers/gpu/drm/i915/display/intel_display.h @@ -57,6 +57,7 @@ struct intel_plane; struct intel_plane_state; struct intel_remapped_info; struct intel_rotation_info; +struct pci_dev; enum i915_gpio { GPIOA,
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --] Hi all, After merging the irqchip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/cpuid.ko] Error 255 arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/msr.ko] Error 255 arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .retpoline_sites, skipping arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .ibt_endbr_seal, skipping arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/events/intel/intel-uncore.ko] Error 255 I couldn't see anything int the irqchip tree that would cause this, so I deleted my object directory and redid the build and this time it succeeded. I suspect some change in the tip tree has brought this on (it is merged just a bit before the irqchip tree). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --] Hi all, On Tue, 15 Mar 2022 14:06:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the irqchip tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/cpuid.ko] Error 255 > arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/msr.ko] Error 255 > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .retpoline_sites, skipping > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .ibt_endbr_seal, skipping > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/events/intel/intel-uncore.ko] Error 255 > > I couldn't see anything int the irqchip tree that would cause this, > so I deleted my object directory and redid the build and this time > it succeeded. > > I suspect some change in the tip tree has brought this on (it is merged > just a bit before the irqchip tree). This time after the merging usb trees: drivers/phy/qualcomm/phy-qcom-usb-hs.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hs.ko] Error 255 drivers/phy/qualcomm/phy-qcom-usb-hsic.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hsic.ko] Error 255 I just removed the drivers/phy/qualcomm directory from the object tree and rebuilt. Then got this: drivers/phy/ti/phy-tusb1210.o: warning: objtool: file already has .orc_unwind section, skipping make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: drivers/phy/ti/phy-tusb1210.ko] Error 255 So removed the drivers/phy/ti directory and rebuilt and the build succeeded. I assume that something is being left around or reprocessed when it should not be. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2519 bytes --] Hi all, On Tue, 15 Mar 2022 16:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Tue, 15 Mar 2022 14:06:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > After merging the irqchip tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/cpuid.ko] Error 255 > > arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/msr.ko] Error 255 > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .retpoline_sites, skipping > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .ibt_endbr_seal, skipping > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/events/intel/intel-uncore.ko] Error 255 > > > > I couldn't see anything int the irqchip tree that would cause this, > > so I deleted my object directory and redid the build and this time > > it succeeded. > > > > I suspect some change in the tip tree has brought this on (it is merged > > just a bit before the irqchip tree). > > This time after the merging usb trees: > > drivers/phy/qualcomm/phy-qcom-usb-hs.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hs.ko] Error 255 > drivers/phy/qualcomm/phy-qcom-usb-hsic.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hsic.ko] Error 255 > > I just removed the drivers/phy/qualcomm directory from the object tree > and rebuilt. > > Then got this: > > drivers/phy/ti/phy-tusb1210.o: warning: objtool: file already has .orc_unwind section, skipping > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: drivers/phy/ti/phy-tusb1210.ko] Error 255 > > So removed the drivers/phy/ti directory and rebuilt and the build > succeeded. > > I assume that something is being left around or reprocessed when it > should not be. Maybe commit 8856dadf7ad3 ("Kbuild: Allow whole module objtool runs") ? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 5697 bytes --] Hi all, On Tue, 15 Mar 2022 16:37:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Tue, 15 Mar 2022 16:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Tue, 15 Mar 2022 14:06:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the irqchip tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping > > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/cpuid.ko] Error 255 > > > arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping > > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/msr.ko] Error 255 > > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .retpoline_sites, skipping > > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .ibt_endbr_seal, skipping > > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .orc_unwind section, skipping > > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/events/intel/intel-uncore.ko] Error 255 > > > > > > I couldn't see anything int the irqchip tree that would cause this, > > > so I deleted my object directory and redid the build and this time > > > it succeeded. > > > > > > I suspect some change in the tip tree has brought this on (it is merged > > > just a bit before the irqchip tree). > > > > This time after the merging usb trees: > > > > drivers/phy/qualcomm/phy-qcom-usb-hs.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hs.ko] Error 255 > > drivers/phy/qualcomm/phy-qcom-usb-hsic.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hsic.ko] Error 255 > > > > I just removed the drivers/phy/qualcomm directory from the object tree > > and rebuilt. > > > > Then got this: > > > > drivers/phy/ti/phy-tusb1210.o: warning: objtool: file already has .orc_unwind section, skipping > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: drivers/phy/ti/phy-tusb1210.ko] Error 255 > > > > So removed the drivers/phy/ti directory and rebuilt and the build > > succeeded. > > > > I assume that something is being left around or reprocessed when it > > should not be. > > Maybe commit > > 8856dadf7ad3 ("Kbuild: Allow whole module objtool runs") > > ? And after merging the scsi tree: arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .static_call_sites section, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .retpoline_sites, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .ibt_endbr_seal, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .static_call_sites section, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .ibt_endbr_seal, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .static_call_sites section, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .retpoline_sites, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .ibt_endbr_seal, skipping arch/x86/crypto/aegis128-aesni.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .static_call_sites section, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .ibt_endbr_seal, skipping arch/x86/crypto/aesni-intel.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/kernel/cpu/mce/mce-inject.o: warning: objtool: file already has .static_call_sites section, skipping arch/x86/kernel/cpu/mce/mce-inject.o: warning: objtool: file already has .retpoline_sites, skipping arch/x86/kernel/cpu/mce/mce-inject.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping crypto/aegis128.o: warning: objtool: file already has .static_call_sites section, skipping crypto/aegis128.o: warning: objtool: file already has .orc_unwind section, skipping crypto/arc4.o: warning: objtool: file already has .orc_unwind section, skipping crypto/async_tx/async_memcpy.o: warning: objtool: file already has .static_call_sites section, skipping crypto/async_tx/async_memcpy.o: warning: objtool: file already has .retpoline_sites, skipping crypto/async_tx/async_memcpy.o: warning: objtool: file already has .orc_unwind section, skipping and so on ... I finally got fed up with rebuilding and so reverted these commits c7d90e15b895 ("x86: Fix {int3,ibt}_selftest() vs LTO") 8959fcf5650e ("x86/alternative: Use .ibt_endbr_seal to seal indirect calls") 49f8cb48085d ("objtool: Find unused ENDBR instructions") b87d2fcee362 ("objtool: Validate IBT assumptions") df280fcb49f9 ("objtool: Add IBT/ENDBR decoding") 51727f8e4a1a ("objtool: Read the NOENDBR annotation") 8856dadf7ad3 ("Kbuild: Allow whole module objtool runs") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Mar 15, 2022 at 04:37:47PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 15 Mar 2022 16:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Tue, 15 Mar 2022 14:06:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the irqchip tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > arch/x86/kernel/cpuid.o: warning: objtool: file already has .orc_unwind section, skipping
> > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/cpuid.ko] Error 255
> > > arch/x86/kernel/msr.o: warning: objtool: file already has .orc_unwind section, skipping
> > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/kernel/msr.ko] Error 255
> > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .retpoline_sites, skipping
> > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .ibt_endbr_seal, skipping
> > > arch/x86/events/intel/intel-uncore.o: warning: objtool: file already has .orc_unwind section, skipping
> > > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: arch/x86/events/intel/intel-uncore.ko] Error 255
> > >
> > > I couldn't see anything int the irqchip tree that would cause this,
> > > so I deleted my object directory and redid the build and this time
> > > it succeeded.
> > >
> > > I suspect some change in the tip tree has brought this on (it is merged
> > > just a bit before the irqchip tree).
> >
> > This time after the merging usb trees:
> >
> > drivers/phy/qualcomm/phy-qcom-usb-hs.o: warning: objtool: file already has .orc_unwind section, skipping
> > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hs.ko] Error 255
> > drivers/phy/qualcomm/phy-qcom-usb-hsic.o: warning: objtool: file already has .orc_unwind section, skipping
> > make[3]: *** [scripts/Makefile.modfinal:61: drivers/phy/qualcomm/phy-qcom-usb-hsic.ko] Error 255
> >
> > I just removed the drivers/phy/qualcomm directory from the object tree
> > and rebuilt.
> >
> > Then got this:
> >
> > drivers/phy/ti/phy-tusb1210.o: warning: objtool: file already has .orc_unwind section, skipping
> > make[3]: *** [/home/sfr/next/next/scripts/Makefile.modfinal:61: drivers/phy/ti/phy-tusb1210.ko] Error 255
> >
> > So removed the drivers/phy/ti directory and rebuilt and the build
> > succeeded.
> >
> > I assume that something is being left around or reprocessed when it
> > should not be.
>
> Maybe commit
>
> 8856dadf7ad3 ("Kbuild: Allow whole module objtool runs")
Almost, it's this in combination with a follow up that uses it. I've
just managed to beat it into submission, will hopefully be cured for
tomorrow's build.
[-- Attachment #1: Type: text/plain, Size: 307 bytes --] Hi Peter, On Tue, 15 Mar 2022 10:22:19 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > > Almost, it's this in combination with a follow up that uses it. I've > just managed to beat it into submission, will hopefully be cured for > tomorrow's build. Thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/lib/code-patching.c: In function 'text_area_cpu_up_mm': arch/powerpc/lib/code-patching.c:157:14: error: implicit declaration of function 'copy_init_mm' [-Werror=implicit-function-declaration] 157 | mm = copy_init_mm(); | ^~~~~~~~~~~~ Caused by commit 107b6828a7cd ("x86/mm: Use mm_alloc() in poking_init()") interacting with commit 55a02e6ea958 ("powerpc/code-patching: Use temporary mm for Radix MMU") from the powerpc tree. I partially reverted commit 107b6828a7cd - I left the change to arch/x86/mm/init.c applied. Though, I wonder if the powerpc tree should use mm_alloc() instead of copy_init_mm() as well? The tip tree commit says: Instead of duplicating init_mm, allocate a fresh mm. The advantage is that mm_alloc() has much simpler dependencies. Additionally it makes more conceptual sense, init_mm has no (and must not have) user state to duplicate. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, 2022-12-02 at 11:26 +1100, Stephen Rothwell wrote:
> Though, I wonder if the powerpc tree should
> use mm_alloc() instead of copy_init_mm() as well? The tip tree
> commit
> says:
>
> Instead of duplicating init_mm, allocate a fresh mm. The
> advantage is
> that mm_alloc() has much simpler dependencies. Additionally it
> makes
> more conceptual sense, init_mm has no (and must not have) user
> state
> to duplicate.
>
Yes, that seems fine. All we need is that the page table isn't shared
and the kernel mappings are the same as in init_mm. It seems mm_alloc()
does this at some point.
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/lib/code-patching.c: In function 'text_area_cpu_up_mm':
> arch/powerpc/lib/code-patching.c:157:14: error: implicit declaration of function 'copy_init_mm' [-Werror=implicit-function-declaration]
> 157 | mm = copy_init_mm();
> | ^~~~~~~~~~~~
>
> Caused by commit
>
> 107b6828a7cd ("x86/mm: Use mm_alloc() in poking_init()")
>
> interacting with commit
>
> 55a02e6ea958 ("powerpc/code-patching: Use temporary mm for Radix MMU")
>
> from the powerpc tree.
>
> I partially reverted commit 107b6828a7cd - I left the change to
> arch/x86/mm/init.c applied. Though, I wonder if the powerpc tree should
> use mm_alloc() instead of copy_init_mm() as well? The tip tree commit
> says:
>
> Instead of duplicating init_mm, allocate a fresh mm. The advantage is
> that mm_alloc() has much simpler dependencies. Additionally it makes
> more conceptual sense, init_mm has no (and must not have) user state
> to duplicate.
I needed to rebase my next anyway, so I've squashed in a change to use
mm_alloc() in the powerpc commit. So this issue will be gone on Monday.
cheers
[-- Attachment #1: Type: text/plain, Size: 2895 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/uaccess.h:11, from include/linux/sched/task.h:11, from include/linux/sched/signal.h:9, from include/linux/rcuwait.h:6, from include/linux/percpu-rwsem.h:7, from include/linux/fs.h:33, from include/linux/huge_mm.h:8, from include/linux/mm.h:726, from drivers/media/common/videobuf2/frame_vector.c:5: drivers/media/common/videobuf2/frame_vector.c: In function 'get_vaddr_frames': drivers/media/common/videobuf2/frame_vector.c:46:31: error: 'mm' undeclared (first use in this function); did you mean 'tm'? 46 | start = untagged_addr(mm, start); | ^~ arch/x86/include/asm/uaccess.h:38:28: note: in definition of macro 'untagged_addr' 38 | __addr &= (mm)->context.untag_mask | sign; \ | ^~ drivers/media/common/videobuf2/frame_vector.c:46:31: note: each undeclared identifier is reported only once for each function it appears in 46 | start = untagged_addr(mm, start); | ^~ arch/x86/include/asm/uaccess.h:38:28: note: in definition of macro 'untagged_addr' 38 | __addr &= (mm)->context.untag_mask | sign; \ | ^~ Caused by commit 062c9b2996e9 ("mm: Pass down mm_struct to untagged_addr()") interacting with commit 6647e76ab623 ("v4l2: don't fall back to follow_pfn() if pin_user_pages_fast() fails") from Linus' tree. I have applied the following merge fix patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 5 Dec 2022 11:55:52 +1100 Subject: [PATCH] fix up for "mm: Pass down mm_struct to untagged_addr()" interacting with "v4l2: don't fall back to follow_pfn() if pin_user_pages_fast() fails" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/media/common/videobuf2/frame_vector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c index 18124929b18d..13455a76a37e 100644 --- a/drivers/media/common/videobuf2/frame_vector.c +++ b/drivers/media/common/videobuf2/frame_vector.c @@ -43,7 +43,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, if (WARN_ON_ONCE(nr_frames > vec->nr_allocated)) nr_frames = vec->nr_allocated; - start = untagged_addr(mm, start); + start = untagged_addr(current->mm, start); ret = pin_user_pages_fast(start, nr_frames, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/uaccess.h:11, from include/linux/sched/task.h:11, from include/linux/sched/signal.h:9, from include/linux/rcuwait.h:6, from include/linux/percpu-rwsem.h:7, from include/linux/fs.h:33, from include/linux/highmem.h:5, from include/linux/bvec.h:10, from include/linux/blk_types.h:10, from include/linux/blkdev.h:9, from drivers/scsi/scsi_ioctl.c:9: drivers/scsi/scsi_ioctl.c: In function 'sg_scsi_ioctl': arch/x86/include/asm/uaccess.h:46:9: error: cast specifies array type 46 | (__force __typeof__(ptr))__ptrval; \ | ^ arch/x86/include/asm/uaccess.h:107:38: note: in definition of macro '__typefits' 107 | __builtin_choose_expr(sizeof(x)<=sizeof(type),(unsigned type)0,not) | ^ arch/x86/include/asm/uaccess.h:130:18: note: in expansion of macro '__inttype' 130 | register __inttype(*(ptr)) __val_gu asm("%"_ASM_DX); \ | ^~~~~~~~~ arch/x86/include/asm/uaccess.h:162:9: note: in expansion of macro 'do_get_user_call' 162 | do_get_user_call(get_user,x,untagged_ptr(current->mm, ptr)); \ | ^~~~~~~~~~~~~~~~ arch/x86/include/asm/uaccess.h:162:37: note: in expansion of macro 'untagged_ptr' 162 | do_get_user_call(get_user,x,untagged_ptr(current->mm, ptr)); \ | ^~~~~~~~~~~~ drivers/scsi/scsi_ioctl.c:522:13: note: in expansion of macro 'get_user' 522 | if (get_user(opcode, sic->data)) | ^~~~~~~~ Caused by commit ce66a02538f3 ("x86/mm: Fix sparse warnings in untagged_ptr()") (the scsi code above has not changed since at least February ...) I have reverted that commit for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Dec 13, 2022 at 12:40:23PM +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 include/linux/uaccess.h:11, > from include/linux/sched/task.h:11, > from include/linux/sched/signal.h:9, > from include/linux/rcuwait.h:6, > from include/linux/percpu-rwsem.h:7, > from include/linux/fs.h:33, > from include/linux/highmem.h:5, > from include/linux/bvec.h:10, > from include/linux/blk_types.h:10, > from include/linux/blkdev.h:9, > from drivers/scsi/scsi_ioctl.c:9: > drivers/scsi/scsi_ioctl.c: In function 'sg_scsi_ioctl': > arch/x86/include/asm/uaccess.h:46:9: error: cast specifies array type > 46 | (__force __typeof__(ptr))__ptrval; \ > | ^ > arch/x86/include/asm/uaccess.h:107:38: note: in definition of macro '__typefits' > 107 | __builtin_choose_expr(sizeof(x)<=sizeof(type),(unsigned type)0,not) > | ^ > arch/x86/include/asm/uaccess.h:130:18: note: in expansion of macro '__inttype' > 130 | register __inttype(*(ptr)) __val_gu asm("%"_ASM_DX); \ > | ^~~~~~~~~ > arch/x86/include/asm/uaccess.h:162:9: note: in expansion of macro 'do_get_user_call' > 162 | do_get_user_call(get_user,x,untagged_ptr(current->mm, ptr)); \ > | ^~~~~~~~~~~~~~~~ > arch/x86/include/asm/uaccess.h:162:37: note: in expansion of macro 'untagged_ptr' > 162 | do_get_user_call(get_user,x,untagged_ptr(current->mm, ptr)); \ > | ^~~~~~~~~~~~ > drivers/scsi/scsi_ioctl.c:522:13: note: in expansion of macro 'get_user' > 522 | if (get_user(opcode, sic->data)) > | ^~~~~~~~ > > Caused by commit > > ce66a02538f3 ("x86/mm: Fix sparse warnings in untagged_ptr()") > > (the scsi code above has not changed since at least February ...) > > I have reverted that commit for today. There is a patch from Kirill that fixes this issue. It seems that its on it's way to be merged [1]. Thanks and BR, Ricardo [1]. https://lore.kernel.org/lkml/166986602299.2101055.4152803267481265665.b4-ty@oracle.com/
Hi all, After merging the rcu tree, today's linux-next build (arm64 defconfig) failed like this: /tmp/next/build/mm/migrate.c: In function 'remove_migration_pte': /tmp/next/build/mm/migrate.c:222:31: error: too few arguments to function 'pte_mkwrite' 222 | pte = pte_mkwrite(pte); | ^~~~~~~~~~~ In file included from /tmp/next/build/include/linux/pgtable.h:6, from /tmp/next/build/include/linux/mm.h:29, from /tmp/next/build/include/linux/migrate.h:5, from /tmp/next/build/mm/migrate.c:16: /tmp/next/build/arch/arm64/include/asm/pgtable.h:190:21: note: declared here 190 | static inline pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) | ^~~~~~~~~~~ Caused by commit 717f95b494ac36 ("mm: don't check VMA write permissions if the PTE/PMD indicates write permissions") from the mm tree interacting with 74fd30bd28e4c7 ("mm: Make pte_mkwrite() take a VMA") from the tip tree. I've applied the fixup below diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 1cc86d0a669e8..c3cc20c1b26cb 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2235,7 +2235,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, } else { entry = mk_pte(page + i, READ_ONCE(vma->vm_page_prot)); if (write) - entry = pte_mkwrite(entry); + entry = pte_mkwrite(entry, vma); if (anon_exclusive) SetPageAnonExclusive(page + i); if (!young) @@ -3272,7 +3272,7 @@ void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, struct page *new) if (pmd_swp_soft_dirty(*pvmw->pmd)) pmde = pmd_mksoft_dirty(pmde); if (is_writable_migration_entry(entry)) - pmde = pmd_mkwrite(pmde); + pmde = pmd_mkwrite(pmde, vma); if (pmd_swp_uffd_wp(*pvmw->pmd)) pmde = pmd_mkuffd_wp(pmde); if (!is_migration_entry_young(entry)) diff --git a/mm/migrate.c b/mm/migrate.c index 01cac26a31279..8b46b722f1a44 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -219,7 +219,7 @@ static bool remove_migration_pte(struct folio *folio, if (folio_test_dirty(folio) && is_migration_entry_dirty(entry)) pte = pte_mkdirty(pte); if (is_writable_migration_entry(entry)) - pte = pte_mkwrite(pte); + pte = pte_mkwrite(pte, vma); else if (pte_swp_uffd_wp(*pvmw.pte)) pte = pte_mkuffd_wp(pte); -- 2.30.2
On Wed, Apr 19, 2023 at 07:21:36PM +0100, broonie@kernel.org wrote: > Hi all, > > After merging the rcu tree, today's linux-next build (arm64 defconfig) > failed like this: > > /tmp/next/build/mm/migrate.c: In function 'remove_migration_pte': > /tmp/next/build/mm/migrate.c:222:31: error: too few arguments to function 'pte_mkwrite' > 222 | pte = pte_mkwrite(pte); > | ^~~~~~~~~~~ > In file included from /tmp/next/build/include/linux/pgtable.h:6, > from /tmp/next/build/include/linux/mm.h:29, > from /tmp/next/build/include/linux/migrate.h:5, > from /tmp/next/build/mm/migrate.c:16: > /tmp/next/build/arch/arm64/include/asm/pgtable.h:190:21: note: declared here > 190 | static inline pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) > | ^~~~~~~~~~~ > > Caused by commit > > 717f95b494ac36 ("mm: don't check VMA write permissions if the PTE/PMD indicates write permissions") > > from the mm tree interacting with > > 74fd30bd28e4c7 ("mm: Make pte_mkwrite() take a VMA") > > from the tip tree. I've applied the fixup below Thanks for letting us know - we'll keep this in mind when sending the piles of patches to Linus next week. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Hi all, After merging the tip tree, today's linux-next build (arm multi_v7_defconfig) failed like this: /tmp/next/build/kernel/time/posix-cpu-timers.c: In function 'posix_cpu_timer_wait_running_nsleep': /tmp/next/build/kernel/time/posix-cpu-timers.c:1310:30: error: 'timr' is a pointer; did you mean to use '->'? 1310 | spin_unlock_irq(&timr.it_lock); | ^ | -> /tmp/next/build/kernel/time/posix-cpu-timers.c:1312:28: error: 'timr' is a pointer; did you mean to use '->'? 1312 | spin_lock_irq(&timr.it_lock); | ^ | -> Caused by commit 2aaae4bf41b101f7e ("posix-cpu-timers: Implement the missing timer_wait_running callback") The !POSIX_CPU_TIMERS_TASK_WORK case wasn't fully updated. I've used the version of the tip tree from next-20230420 instead.
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allnoconfig) failed like this: In file included from include/linux/mem_encrypt.h:17, from arch/x86/include/asm/page_types.h:7, from arch/x86/include/asm/page.h:9, from arch/x86/include/asm/thread_info.h:12, from include/linux/thread_info.h:60, from arch/x86/include/asm/preempt.h:9, from include/linux/preempt.h:78, from include/linux/spinlock.h:56, from include/linux/swait.h:7, from include/linux/completion.h:12, from include/linux/crypto.h:15, from arch/x86/kernel/asm-offsets.c:9: arch/x86/include/asm/mem_encrypt.h:23:20: error: static declaration of 'mem_encrypt_init' follows non-static declaration 23 | static inline void mem_encrypt_init(void) { } | ^~~~~~~~~~~~~~~~ In file included from include/linux/printk.h:6, from include/linux/kernel.h:30, from arch/x86/include/asm/percpu.h:27, from arch/x86/include/asm/preempt.h:6: include/linux/init.h:158:6: note: previous declaration of 'mem_encrypt_init' with type 'void(void)' 158 | void mem_encrypt_init(void); | ^~~~~~~~~~~~~~~~ Caused by commits 439e17576eb4 ("init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init()") 0a9567ac5e6a ("x86/mem_encrypt: Unbreak the AMD_MEM_ENCRYPT=n build") from the tip tree interacting with commit ad1a48301f65 ("init: consolidate prototypes in linux/init.h") From the mm tree. I have applied the following merge fix patch for today (but I think it can be consolidated into the mm tree commit - along with removing the parts that remove this declaration from elsewhere). From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 20 Jun 2023 14:30:52 +1000 Subject: [PATCH] fix up for "init: consolidate prototypes in linux/init.h" interacting with commits 439e17576eb4 ("init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init()") 0a9567ac5e6a ("x86/mem_encrypt: Unbreak the AMD_MEM_ENCRYPT=n build") from the tip tree. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- include/linux/init.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/init.h b/include/linux/init.h index 1200fa99e848..266c3e1640d4 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -155,7 +155,6 @@ void __init init_rootfs(void); void init_IRQ(void); void time_init(void); -void mem_encrypt_init(void); void poking_init(void); void pgtable_cache_init(void); -- 2.39.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3138 bytes --] Hi all, After merging the tip tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20, from arch/powerpc/include/asm/book3s/64/mmu.h:32, from arch/powerpc/include/asm/mmu.h:396, from arch/powerpc/include/asm/lppaca.h:46, from arch/powerpc/include/asm/paca.h:18, from arch/powerpc/include/asm/current.h:13, from include/linux/thread_info.h:23, from include/asm-generic/preempt.h:5, from ./arch/powerpc/include/generated/asm/preempt.h:1, from include/linux/preempt.h:79, from include/linux/spinlock.h:56, from include/linux/mmzone.h:8, from include/linux/gfp.h:7, from include/linux/mm.h:7, from mm/huge_memory.c:8: mm/huge_memory.c: In function 'maybe_pud_mkwrite': arch/powerpc/include/asm/book3s/64/pgtable.h:934:41: error: too few arguments to function 'pte_mkwrite' 934 | #define pud_mkwrite(pud) pte_pud(pte_mkwrite(pud_pte(pud))) | ^~~~~~~~~~~ mm/huge_memory.c:935:23: note: in expansion of macro 'pud_mkwrite' 935 | pud = pud_mkwrite(pud); | ^~~~~~~~~~~ In file included from include/linux/mm.h:29: include/linux/pgtable.h:593:21: note: declared here 593 | static inline pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) | ^~~~~~~~~~~ Caused by commit 161e393c0f63 ("mm: Make pte_mkwrite() take a VMA") interacting with commit 6440c7b067ef ("powerpc/book3s64/mm: enable transparent pud hugepage") from the mm-stable tree. I have applied the following patch for today (hopefully it makes sense): From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 15 Aug 2023 15:15:23 +1000 Subject: [PATCH] fix up for "mm: Make pte_mkwrite() take a VMA" interacting with commit 6440c7b067ef ("powerpc/book3s64/mm: enable transparent pud hugepage") from the mm-stable tree. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h index 136232a89739..5c497c862d75 100644 --- a/arch/powerpc/include/asm/book3s/64/pgtable.h +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h @@ -931,7 +931,7 @@ static inline pte_t *pudp_ptep(pud_t *pud) #define pud_mkdirty(pud) pte_pud(pte_mkdirty(pud_pte(pud))) #define pud_mkclean(pud) pte_pud(pte_mkclean(pud_pte(pud))) #define pud_mkyoung(pud) pte_pud(pte_mkyoung(pud_pte(pud))) -#define pud_mkwrite(pud) pte_pud(pte_mkwrite(pud_pte(pud))) +#define pud_mkwrite(pud) pte_pud(pte_mkwrite_novma(pud_pte(pud))) #define pud_write(pud) pte_write(pud_pte(pud)) #ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY -- 2.40.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 2023-08-15 at 15:29 +1000, Stephen Rothwell wrote:
> Caused by commit
>
> 161e393c0f63 ("mm: Make pte_mkwrite() take a VMA")
>
> interacting with commit
>
> 6440c7b067ef ("powerpc/book3s64/mm: enable transparent pud
> hugepage")
>
> from the mm-stable tree.
>
> I have applied the following patch for today (hopefully it makes
> sense):
Thanks. Seems reasonable to me.
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --] Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/compiler_types.h:89, from <command-line>: kernel/irq/irq_sim.c: In function 'irq_domain_create_sim': include/linux/compiler_attributes.h:76:41: error: expected expression before '__attribute__' 76 | #define __cleanup(func) __attribute__((__cleanup__(func))) | ^~~~~~~~~~~~~ include/linux/cleanup.h:64:25: note: in expansion of macro '__cleanup' 64 | #define __free(_name) __cleanup(__free_##_name) | ^~~~~~~~~ kernel/irq/irq_sim.c:173:19: note: in expansion of macro '__free' 173 | pending = __free(bitmap) = bitmap_zalloc(num_irqs, GFP_KERNEL); | ^~~~~~ Caused by commit 590610d72a79 ("genirq/irq_sim: Shrink code by using cleanup helpers") I have used the tip tree from next-20240125 for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, 29 Jan 2024 at 02:22, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from include/linux/compiler_types.h:89, > from <command-line>: > kernel/irq/irq_sim.c: In function 'irq_domain_create_sim': > include/linux/compiler_attributes.h:76:41: error: expected expression before '__attribute__' > 76 | #define __cleanup(func) __attribute__((__cleanup__(func))) > | ^~~~~~~~~~~~~ > include/linux/cleanup.h:64:25: note: in expansion of macro '__cleanup' > 64 | #define __free(_name) __cleanup(__free_##_name) > | ^~~~~~~~~ > kernel/irq/irq_sim.c:173:19: note: in expansion of macro '__free' > 173 | pending = __free(bitmap) = bitmap_zalloc(num_irqs, GFP_KERNEL); > | ^~~~~~ > > Caused by commit > > 590610d72a79 ("genirq/irq_sim: Shrink code by using cleanup helpers") > > I have used the tip tree from next-20240125 for today. > > -- > Cheers, > Stephen Rothwell For the record: this is not my code. This is what I sent: https://lore.kernel.org/all/20240122124243.44002-5-brgl@bgdev.pl/ Applying my version will fix the problem. Thanks, Bartosz