linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build failure after merge of the tip tree
@ 2011-10-05  6:25 Stephen Rothwell
  2011-10-05  8:46 ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2011-10-05  6:25 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Huang Ying, David Miller, netdev

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

Hi all,

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

net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
net/rds/xlist.h with llist") from the net tree.  The former commit
removes the declarations of llist_del_first() and llist_add_batch() with
no explanation (and probably by accident since the definitions still
exist).

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 5 Oct 2011 17:16:29 +1100
Subject: [PATCH] llist: add back llist_add_batch and llist_del_first

Commit 1230db8e1543 ("llist: Make some llist functions inline") appears
to have deleted the definitions by accident.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/llist.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index 837fb4a..7287734 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -178,4 +178,10 @@ static inline struct llist_node *llist_del_all(struct llist_head *head)
 {
 	return xchg(&head->first, NULL);
 }
+
+extern bool llist_add_batch(struct llist_node *new_first,
+			    struct llist_node *new_last,
+			    struct llist_head *head);
+extern struct llist_node *llist_del_first(struct llist_head *head);
+
 #endif /* LLIST_H */
-- 
1.7.6.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* Re: linux-next: build failure after merge of the tip tree
  2011-10-05  6:25 linux-next: build failure after merge of the tip tree Stephen Rothwell
@ 2011-10-05  8:46 ` Peter Zijlstra
  2011-10-11  6:15   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2011-10-05  8:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Huang Ying, David Miller, netdev

On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> 
> Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> net/rds/xlist.h with llist") from the net tree.  The former commit
> removes the declarations of llist_del_first() and llist_add_batch() with
> no explanation (and probably by accident since the definitions still
> exist).

Ugh yes, my bad. Ingo objected to inlining all those functions and I
then screwed up. There are no users of those two functions in my tree.

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

* Re: linux-next: build failure after merge of the tip tree
  2011-10-05  8:46 ` Peter Zijlstra
@ 2011-10-11  6:15   ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2011-10-11  6:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Huang Ying, David Miller, netdev

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

Hi all,

On Wed, 05 Oct 2011 10:46:13 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> > net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> > net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> > net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> > net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > 
> > Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> > interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> > net/rds/xlist.h with llist") from the net tree.  The former commit
> > removes the declarations of llist_del_first() and llist_add_batch() with
> > no explanation (and probably by accident since the definitions still
> > exist).
> 
> Ugh yes, my bad. Ingo objected to inlining all those functions and I
> then screwed up. There are no users of those two functions in my tree.

So can we have that fixed, please?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* Re: linux-next: build failure after merge of the tip tree
  2024-01-29  1:22 Stephen Rothwell
@ 2024-01-29  8:14 ` Bartosz Golaszewski
  0 siblings, 0 replies; 357+ messages in thread
From: Bartosz Golaszewski @ 2024-01-29  8:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2024-01-29  1:22 Stephen Rothwell
  2024-01-29  8:14 ` Bartosz Golaszewski
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2024-01-29  1:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Bartosz Golaszewski, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2023-08-15  5:29 Stephen Rothwell
@ 2023-08-15 15:54 ` Edgecombe, Rick P
  0 siblings, 0 replies; 357+ messages in thread
From: Edgecombe, Rick P @ 2023-08-15 15:54 UTC (permalink / raw)
  To: sfr, tglx, mingo, hpa, peterz, akpm
  Cc: aneesh.kumar, linux-next, linux-kernel, dave.hansen

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.

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

* linux-next: build failure after merge of the tip tree
@ 2023-08-15  5:29 Stephen Rothwell
  2023-08-15 15:54 ` Edgecombe, Rick P
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2023-08-15  5:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Andrew Morton
  Cc: Aneesh Kumar K.V, Dave Hansen, Rick Edgecombe,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2023-06-20  4:53 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2023-06-20  4:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Andrew Morton
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2023-04-21 16:03 broonie
  0 siblings, 0 replies; 357+ messages in thread
From: broonie @ 2023-04-21 16:03 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H . Peter Anvin, Peter Zijlstra
  Cc: stable, Marco Elver, Sebastian Andrzej Siewior, linux-arm-kernel,
	Linux Kernel Mailing List, Linux Next Mailing List

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.

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

* Re: linux-next: Build failure after merge of the tip tree
  2023-04-19 18:21 linux-next: Build " broonie
@ 2023-04-19 18:50 ` Borislav Petkov
  0 siblings, 0 replies; 357+ messages in thread
From: Borislav Petkov @ 2023-04-19 18:50 UTC (permalink / raw)
  To: broonie
  Cc: David Hildenbrand, Kirill A . Shutemov, Thomas Gleixner,
	Ingo Molnar, H . Peter Anvin, Peter Zijlstra, Rick Edgecombe,
	Dave Hansen, Kees Cook, Mike Rapoport, Michael Ellerman,
	Mel Gorman, Peter Xu, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* linux-next: Build failure after merge of the tip tree
@ 2023-04-19 18:21 broonie
  2023-04-19 18:50 ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: broonie @ 2023-04-19 18:21 UTC (permalink / raw)
  To: David Hildenbrand, Kirill A . Shutemov, Thomas Gleixner,
	Ingo Molnar, H . Peter Anvin, Peter Zijlstra, Rick Edgecombe,
	Dave Hansen, Kees Cook, Borislav Petkov, Mike Rapoport,
	Michael Ellerman
  Cc: Mel Gorman, Peter Xu, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

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


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

* Re: linux-next: build failure after merge of the tip tree
  2022-12-13  1:40 linux-next: build " Stephen Rothwell
@ 2022-12-15 16:34 ` Ricardo Neri
  0 siblings, 0 replies; 357+ messages in thread
From: Ricardo Neri @ 2022-12-15 16:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zilstra,
	Dave Hansen, Kirill A. Shutemov, Linux Kernel Mailing List,
	Linux Next Mailing List, Martin K. Petersen

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/

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

* linux-next: build failure after merge of the tip tree
@ 2022-12-13  1:40 Stephen Rothwell
  2022-12-15 16:34 ` Ricardo Neri
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2022-12-13  1:40 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Dave Hansen, Kirill A. Shutemov, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2022-12-05  1:15 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2022-12-05  1:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linus Torvalds, Dave Hansen, Kirill A. Shutemov,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-12-02  0:26 Stephen Rothwell
  2022-12-02  1:33 ` Benjamin Gray
@ 2022-12-02  9:37 ` Michael Ellerman
  1 sibling, 0 replies; 357+ messages in thread
From: Michael Ellerman @ 2022-12-02  9:37 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Benjamin Gray, Christopher M. Riedl, Linux Kernel Mailing List,
	Linux Next Mailing List, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-12-02  0:26 Stephen Rothwell
@ 2022-12-02  1:33 ` Benjamin Gray
  2022-12-02  9:37 ` Michael Ellerman
  1 sibling, 0 replies; 357+ messages in thread
From: Benjamin Gray @ 2022-12-02  1:33 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Michael Ellerman
  Cc: Christopher M. Riedl, Linux Kernel Mailing List,
	Linux Next Mailing List, PowerPC

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.

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

* linux-next: build failure after merge of the tip tree
@ 2022-12-02  0:26 Stephen Rothwell
  2022-12-02  1:33 ` Benjamin Gray
  2022-12-02  9:37 ` Michael Ellerman
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2022-12-02  0:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Michael Ellerman
  Cc: Benjamin Gray, Christopher M. Riedl, Linux Kernel Mailing List,
	Linux Next Mailing List, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-03-15  9:22     ` Peter Zijlstra
@ 2022-03-15 10:41       ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2022-03-15 10:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-03-15  5:37   ` Stephen Rothwell
  2022-03-15  8:42     ` Stephen Rothwell
@ 2022-03-15  9:22     ` Peter Zijlstra
  2022-03-15 10:41       ` Stephen Rothwell
  1 sibling, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2022-03-15  9:22 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Kernel Mailing List, Linux Next Mailing List

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.

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

* Re: linux-next: build failure after merge of the tip tree
  2022-03-15  5:37   ` Stephen Rothwell
@ 2022-03-15  8:42     ` Stephen Rothwell
  2022-03-15  9:22     ` Peter Zijlstra
  1 sibling, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2022-03-15  8:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-03-15  5:23 ` Stephen Rothwell
@ 2022-03-15  5:37   ` Stephen Rothwell
  2022-03-15  8:42     ` Stephen Rothwell
  2022-03-15  9:22     ` Peter Zijlstra
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2022-03-15  5:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2022-03-15  3:06 Stephen Rothwell
@ 2022-03-15  5:23 ` Stephen Rothwell
  2022-03-15  5:37   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2022-03-15  5:23 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2022-03-15  3:06 Stephen Rothwell
  2022-03-15  5:23 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2022-03-15  3:06 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2021-12-13 17:08 broonie
  0 siblings, 0 replies; 357+ messages in thread
From: broonie @ 2021-12-13 17:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H . Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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,

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

* Re: linux-next: build failure after merge of the tip tree
  2021-12-01 22:19       ` Thomas Gleixner
@ 2021-12-01 22:31         ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-12-01 22:31 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Arnd Bergmann,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-12-01 22:17     ` Thomas Gleixner
@ 2021-12-01 22:19       ` Thomas Gleixner
  2021-12-01 22:31         ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Thomas Gleixner @ 2021-12-01 22:19 UTC (permalink / raw)
  To: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-12-01 22:05   ` Stephen Rothwell
@ 2021-12-01 22:17     ` Thomas Gleixner
  2021-12-01 22:19       ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Thomas Gleixner @ 2021-12-01 22:17 UTC (permalink / raw)
  To: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-11-26 10:01 ` Arnd Bergmann
@ 2021-12-01 22:05   ` Stephen Rothwell
  2021-12-01 22:17     ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-12-01 22:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-11-26  3:52 Stephen Rothwell
@ 2021-11-26 10:01 ` Arnd Bergmann
  2021-12-01 22:05   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Arnd Bergmann @ 2021-11-26 10:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Arnd Bergmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2021-11-26  3:52 Stephen Rothwell
  2021-11-26 10:01 ` Arnd Bergmann
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-11-26  3:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-25  4:11 Stephen Rothwell
  2021-10-25  7:42 ` Borislav Petkov
@ 2021-10-28  5:10 ` Stephen Rothwell
  2021-10-28  8:17   ` Borislav Petkov
  1 sibling, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-28  5:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-25  7:58   ` Stephen Rothwell
@ 2021-10-25  8:37     ` Borislav Petkov
  0 siblings, 0 replies; 357+ messages in thread
From: Borislav Petkov @ 2021-10-25  8:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-25  7:42 ` Borislav Petkov
@ 2021-10-25  7:58   ` Stephen Rothwell
  2021-10-25  8:37     ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-25  7:58 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-25  4:11 Stephen Rothwell
@ 2021-10-25  7:42 ` Borislav Petkov
  2021-10-25  7:58   ` Stephen Rothwell
  2021-10-28  5:10 ` Stephen Rothwell
  1 sibling, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-10-25  7:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2021-10-25  4:11 Stephen Rothwell
  2021-10-25  7:42 ` Borislav Petkov
  2021-10-28  5:10 ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-25  4:11 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
  2021-10-18  6:23 Stephen Rothwell
@ 2021-10-18  6:45 ` Qi Zheng
  0 siblings, 0 replies; 357+ messages in thread
From: Qi Zheng @ 2021-10-18  6:45 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Kees Cook, Linux Kernel Mailing List, Linux Next Mailing List



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

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

* linux-next: build failure after merge of the tip tree
@ 2021-10-18  6:23 Stephen Rothwell
  2021-10-18  6:45 ` Qi Zheng
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-18  6:23 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Kees Cook, Qi Zheng, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-06  9:54   ` Stephen Rothwell
@ 2021-10-06  9:56     ` Borislav Petkov
  0 siblings, 0 replies; 357+ messages in thread
From: Borislav Petkov @ 2021-10-06  9:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Arnaldo Carvalho de Melo

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-06  9:31 ` Borislav Petkov
@ 2021-10-06  9:54   ` Stephen Rothwell
  2021-10-06  9:56     ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-06  9:54 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Arnaldo Carvalho de Melo

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-10-06  2:58 Stephen Rothwell
@ 2021-10-06  9:31 ` Borislav Petkov
  2021-10-06  9:54   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-10-06  9:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Arnaldo Carvalho de Melo

+ 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

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

* linux-next: build failure after merge of the tip tree
@ 2021-10-06  2:58 Stephen Rothwell
  2021-10-06  9:31 ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-10-06  2:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-06-28  3:36 Stephen Rothwell
@ 2021-06-28  5:42 ` Ingo Molnar
  0 siblings, 0 replies; 357+ messages in thread
From: Ingo Molnar @ 2021-06-28  5:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List


* 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

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

* linux-next: build failure after merge of the tip tree
@ 2021-06-28  3:36 Stephen Rothwell
  2021-06-28  5:42 ` Ingo Molnar
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-06-28  3:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

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.

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

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


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

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

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

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-27 11:50       ` Sedat Dilek
@ 2021-03-27 21:26         ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-27 21:26 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Borislav Petkov, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, David Miller, Networking, Alexei Starovoitov,
	Stanislav Fomichev, Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-26 13:11     ` Borislav Petkov
@ 2021-03-27 11:50       ` Sedat Dilek
  2021-03-27 21:26         ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Sedat Dilek @ 2021-03-27 11:50 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, David Miller, Networking, Alexei Starovoitov,
	Stanislav Fomichev, Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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 -

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-26  8:57   ` Sedat Dilek
@ 2021-03-26 13:11     ` Borislav Petkov
  2021-03-27 11:50       ` Sedat Dilek
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-03-26 13:11 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, David Miller, Networking, Alexei Starovoitov,
	Stanislav Fomichev, Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-22  9:00 ` Borislav Petkov
@ 2021-03-26  8:57   ` Sedat Dilek
  2021-03-26 13:11     ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Sedat Dilek @ 2021-03-26  8:57 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, David Miller, Networking, Alexei Starovoitov,
	Stanislav Fomichev, Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-22  3:37 Stephen Rothwell
  2021-03-22  9:00 ` Borislav Petkov
@ 2021-03-23  8:34 ` Sedat Dilek
  1 sibling, 0 replies; 357+ messages in thread
From: Sedat Dilek @ 2021-03-23  8:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking, Alexei Starovoitov, Stanislav Fomichev,
	Borislav Petkov, Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-22  3:37 Stephen Rothwell
@ 2021-03-22  9:00 ` Borislav Petkov
  2021-03-26  8:57   ` Sedat Dilek
  2021-03-23  8:34 ` Sedat Dilek
  1 sibling, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-03-22  9:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking, Alexei Starovoitov, Stanislav Fomichev,
	Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2021-03-22  3:37 Stephen Rothwell
  2021-03-22  9:00 ` Borislav Petkov
  2021-03-23  8:34 ` Sedat Dilek
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-22  3:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, Networking
  Cc: Alexei Starovoitov, Stanislav Fomichev, Borislav Petkov,
	Daniel Borkmann, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 20:04           ` Ingo Molnar
@ 2021-03-17 21:54             ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-17 21:54 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Borislav Petkov, Stephen Rothwell, Ian Rogers, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 19:18         ` Borislav Petkov
@ 2021-03-17 20:04           ` Ingo Molnar
  2021-03-17 21:54             ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2021-03-17 20:04 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Stephen Rothwell, Ian Rogers, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List


* 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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 18:49       ` Stephen Rothwell
@ 2021-03-17 19:18         ` Borislav Petkov
  2021-03-17 20:04           ` Ingo Molnar
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-03-17 19:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ian Rogers, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 18:02     ` Borislav Petkov
@ 2021-03-17 18:49       ` Stephen Rothwell
  2021-03-17 19:18         ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-17 18:49 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Ian Rogers, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 16:22   ` Ian Rogers
@ 2021-03-17 18:02     ` Borislav Petkov
  2021-03-17 18:49       ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-03-17 18:02 UTC (permalink / raw)
  To: Ian Rogers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17 10:54 ` Borislav Petkov
@ 2021-03-17 16:22   ` Ian Rogers
  2021-03-17 18:02     ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Ian Rogers @ 2021-03-17 16:22 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-17  4:08 Stephen Rothwell
@ 2021-03-17 10:54 ` Borislav Petkov
  2021-03-17 16:22   ` Ian Rogers
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2021-03-17 10:54 UTC (permalink / raw)
  To: Stephen Rothwell, Ian Rogers
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

+ 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

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

* linux-next: build failure after merge of the tip tree
@ 2021-03-17  4:08 Stephen Rothwell
  2021-03-17 10:54 ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-17  4:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-03  9:44 ` Peter Zijlstra
@ 2021-03-03 11:29   ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-03 11:29 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Sebastian Andrzej Siewior, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-03-02 23:38 Stephen Rothwell
@ 2021-03-03  9:44 ` Peter Zijlstra
  2021-03-03 11:29   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2021-03-03  9:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Sebastian Andrzej Siewior, Linux Kernel Mailing List,
	Linux Next Mailing List

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.

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

* linux-next: build failure after merge of the tip tree
@ 2021-03-02 23:38 Stephen Rothwell
  2021-03-03  9:44 ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-03-02 23:38 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Sebastian Andrzej Siewior, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2021-01-14  4:11 Stephen Rothwell
@ 2021-01-14 10:07 ` Borislav Petkov
  0 siblings, 0 replies; 357+ messages in thread
From: Borislav Petkov @ 2021-01-14 10:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Yazen Ghannam, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2021-01-14  4:11 Stephen Rothwell
  2021-01-14 10:07 ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2021-01-14  4:11 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Yazen Ghannam, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

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


* 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

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

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

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-11-09  3:34 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-11-09  3:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Jens Axboe, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-10-09  4:28 Stephen Rothwell
@ 2020-10-09  6:47 ` Vasily Gorbik
  0 siblings, 0 replies; 357+ messages in thread
From: Vasily Gorbik @ 2020-10-09  6:47 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Josh Poimboeuf, Peter Zijlstra,
	Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Mark Rutland, Alexander Shishkin,
	Jiri Olsa, Namhyung Kim, H. Peter Anvin, Masami Hiramatsu,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-10-09  4:28 Stephen Rothwell
  2020-10-09  6:47 ` Vasily Gorbik
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-10-09  4:28 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Josh Poimboeuf, Martin Schwidefsky, Vasily Gorbik,
	Masami Hiramatsu, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-09-08  9:12 Stephen Rothwell
@ 2020-09-08 10:57 ` peterz
  0 siblings, 0 replies; 357+ messages in thread
From: peterz @ 2020-09-08 10:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Steven Rostedt (VMware),
	Linux Next Mailing List, Linux Kernel Mailing List

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)
 
 

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

* linux-next: build failure after merge of the tip tree
@ 2020-09-08  9:12 Stephen Rothwell
  2020-09-08 10:57 ` peterz
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-09-08  9:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Steven Rostedt (VMware),
	Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-09-03  3:51 ` Ingo Molnar
@ 2020-09-03  4:44   ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-09-03  4:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Borislav Petkov, Linux Next Mailing List,
	Linux Kernel Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-09-03  2:35 Stephen Rothwell
@ 2020-09-03  3:51 ` Ingo Molnar
  2020-09-03  4:44   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2020-09-03  3:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Borislav Petkov, Linux Next Mailing List,
	Linux Kernel Mailing List


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

> Hi all,
> 
> After merging the tip tree, today's linux-next build (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

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

* linux-next: build failure after merge of the tip tree
@ 2020-09-03  2:35 Stephen Rothwell
  2020-09-03  3:51 ` Ingo Molnar
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-09-03  2:35 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-08-03  5:45 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-08-03  5:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Dave Airlie, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Lyude Paul

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-07-31  9:57 ` Ingo Molnar
@ 2020-07-31 10:02   ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-07-31 10:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Grygorii Strashko, Linus Torvalds

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-07-31  5:53 Stephen Rothwell
@ 2020-07-31  9:57 ` Ingo Molnar
  2020-07-31 10:02   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2020-07-31  9:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Grygorii Strashko, Linus Torvalds


* 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

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

* linux-next: build failure after merge of the tip tree
@ 2020-07-31  5:53 Stephen Rothwell
  2020-07-31  9:57 ` Ingo Molnar
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-07-31  5:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Grygorii Strashko, Linus Torvalds

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

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

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

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: build failure after merge of the tip tree
  2020-07-07  2:33   ` Stephen Rothwell
@ 2020-07-14  3:50     ` Stephen Rothwell
  2020-07-20  5:37       ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-07-14  3:50 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: build failure after merge of the tip tree
  2020-06-30  2:54 ` Stephen Rothwell
@ 2020-07-07  2:33   ` Stephen Rothwell
  2020-07-14  3:50     ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-07-07  2:33 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: build failure after merge of the tip tree
  2020-06-22  1:37 Stephen Rothwell
@ 2020-06-30  2:54 ` Stephen Rothwell
  2020-07-07  2:33   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-06-30  2:54 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: build failure after merge of the tip tree
  2020-06-21 10:53 ` Borislav Petkov
@ 2020-06-22  1:38   ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-06-22  1:38 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Arnaldo Carvalho de Melo, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Guenter Roeck

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-06-22  1:37 Stephen Rothwell
  2020-06-30  2:54 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-06-22  1:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: build failure after merge of the tip tree
  2020-06-21  6:33 Stephen Rothwell
@ 2020-06-21 10:53 ` Borislav Petkov
  2020-06-22  1:38   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2020-06-21 10:53 UTC (permalink / raw)
  To: Stephen Rothwell, Arnaldo Carvalho de Melo
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Guenter Roeck

+ 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

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

* linux-next: build failure after merge of the tip tree
@ 2020-06-21  6:33 Stephen Rothwell
  2020-06-21 10:53 ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-06-21  6:33 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov, Guenter Roeck

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-25  8:20                     ` Marco Elver
@ 2020-05-25 16:13                       ` Paul E. McKenney
  0 siblings, 0 replies; 357+ messages in thread
From: Paul E. McKenney @ 2020-05-25 16:13 UTC (permalink / raw)
  To: Marco Elver
  Cc: Thomas Gleixner, Borislav Petkov, Stephen Rothwell, Will Deacon,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-25  0:37                   ` Paul E. McKenney
@ 2020-05-25  8:20                     ` Marco Elver
  2020-05-25 16:13                       ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Marco Elver @ 2020-05-25  8:20 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Thomas Gleixner, Borislav Petkov, Stephen Rothwell, Will Deacon,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23 21:23                 ` Paul E. McKenney
@ 2020-05-25  0:37                   ` Paul E. McKenney
  2020-05-25  8:20                     ` Marco Elver
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2020-05-25  0:37 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Borislav Petkov, Stephen Rothwell, Will Deacon, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23 19:05               ` Thomas Gleixner
@ 2020-05-23 21:23                 ` Paul E. McKenney
  2020-05-25  0:37                   ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2020-05-23 21:23 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Borislav Petkov, Stephen Rothwell, Will Deacon, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23 15:06             ` Paul E. McKenney
@ 2020-05-23 19:05               ` Thomas Gleixner
  2020-05-23 21:23                 ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Thomas Gleixner @ 2020-05-23 19:05 UTC (permalink / raw)
  To: paulmck
  Cc: Borislav Petkov, Stephen Rothwell, Will Deacon, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

"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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23  9:54           ` Thomas Gleixner
@ 2020-05-23 15:06             ` Paul E. McKenney
  2020-05-23 19:05               ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2020-05-23 15:06 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Borislav Petkov, Stephen Rothwell, Will Deacon, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23  6:46         ` Borislav Petkov
@ 2020-05-23  9:54           ` Thomas Gleixner
  2020-05-23 15:06             ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Thomas Gleixner @ 2020-05-23  9:54 UTC (permalink / raw)
  To: Borislav Petkov, Paul E. McKenney
  Cc: Stephen Rothwell, Will Deacon, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-23  0:12       ` Paul E. McKenney
@ 2020-05-23  6:46         ` Borislav Petkov
  2020-05-23  9:54           ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2020-05-23  6:46 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Will Deacon, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-22  7:49     ` Stephen Rothwell
@ 2020-05-23  0:12       ` Paul E. McKenney
  2020-05-23  6:46         ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2020-05-23  0:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Will Deacon, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, elver, bp

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-22  7:17   ` Stephen Rothwell
@ 2020-05-22  7:49     ` Stephen Rothwell
  2020-05-23  0:12       ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-05-22  7:49 UTC (permalink / raw)
  To: Will Deacon
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, elver, bp,
	Paul E. McKenney

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-21 17:35 ` Will Deacon
@ 2020-05-22  7:17   ` Stephen Rothwell
  2020-05-22  7:49     ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-05-22  7:17 UTC (permalink / raw)
  To: Will Deacon
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, elver, bp

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-05-21 17:31 Stephen Rothwell
@ 2020-05-21 17:35 ` Will Deacon
  2020-05-22  7:17   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Will Deacon @ 2020-05-21 17:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, elver, bp

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-05-21 17:31 Stephen Rothwell
  2020-05-21 17:35 ` Will Deacon
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-05-21 17:31 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Will Deacon

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-05-15  6:00 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-05-15  6:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Steven Rostedt (VMware)

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-04-03  8:15   ` Baolin Wang
@ 2020-04-03  9:50     ` Sebastian Reichel
  0 siblings, 0 replies; 357+ messages in thread
From: Sebastian Reichel @ 2020-04-03  9:50 UTC (permalink / raw)
  To: Baolin Wang
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Qais Yousef

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-04-01  1:14 ` Stephen Rothwell
@ 2020-04-03  8:15   ` Baolin Wang
  2020-04-03  9:50     ` Sebastian Reichel
  0 siblings, 1 reply; 357+ messages in thread
From: Baolin Wang @ 2020-04-03  8:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Sebastian Reichel, Linux Next Mailing List,
	Linux Kernel Mailing List, Qais Yousef

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-26  2:52 Stephen Rothwell
  2020-03-26 10:59 ` Qais Yousef
@ 2020-04-01  1:14 ` Stephen Rothwell
  2020-04-03  8:15   ` Baolin Wang
  1 sibling, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-04-01  1:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Sebastian Reichel
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Qais Yousef,
	Baolin Wang

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  8:16         ` Borislav Petkov
@ 2020-03-30 11:34           ` H.J. Lu
  0 siblings, 0 replies; 357+ messages in thread
From: H.J. Lu @ 2020-03-30 11:34 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Michael Ellerman, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, PowerPC

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.

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  8:04       ` Michael Ellerman
@ 2020-03-30  8:16         ` Borislav Petkov
  2020-03-30 11:34           ` H.J. Lu
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2020-03-30  8:16 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, H.J. Lu, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  7:48     ` Borislav Petkov
@ 2020-03-30  8:04       ` Michael Ellerman
  2020-03-30  8:16         ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Michael Ellerman @ 2020-03-30  8:04 UTC (permalink / raw)
  To: Borislav Petkov, Stephen Rothwell
  Cc: H.J. Lu, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  4:08   ` Stephen Rothwell
@ 2020-03-30  7:48     ` Borislav Petkov
  2020-03-30  8:04       ` Michael Ellerman
  0 siblings, 1 reply; 357+ messages in thread
From: Borislav Petkov @ 2020-03-30  7:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: H.J. Lu, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, Michael Ellerman, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  3:53 ` H.J. Lu
@ 2020-03-30  4:08   ` Stephen Rothwell
  2020-03-30  7:48     ` Borislav Petkov
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-03-30  4:08 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov, Kees Cook, Michael Ellerman, PowerPC

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-30  3:35 Stephen Rothwell
@ 2020-03-30  3:53 ` H.J. Lu
  2020-03-30  4:08   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: H.J. Lu @ 2020-03-30  3:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov, Kees Cook

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

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

* linux-next: build failure after merge of the tip tree
@ 2020-03-30  3:35 Stephen Rothwell
  2020-03-30  3:53 ` H.J. Lu
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2020-03-30  3:35 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, H.J. Lu,
	Borislav Petkov, Kees Cook

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

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

* Re: linux-next: build failure after merge of the tip tree
  2020-03-26  2:52 Stephen Rothwell
@ 2020-03-26 10:59 ` Qais Yousef
  2020-04-01  1:14 ` Stephen Rothwell
  1 sibling, 0 replies; 357+ messages in thread
From: Qais Yousef @ 2020-03-26 10:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Sebastian Reichel, Linux Next Mailing List,
	Linux Kernel Mailing List, Baolin Wang

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



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

* linux-next: build failure after merge of the tip tree
@ 2020-03-26  2:52 Stephen Rothwell
  2020-03-26 10:59 ` Qais Yousef
  2020-04-01  1:14 ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2020-03-26  2:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Sebastian Reichel
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Qais Yousef,
	Baolin Wang

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

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

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

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

Hi all,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Applied.  Thanks!

Alex

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

from the drm tree interacting with commit

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

from the tip tree.

I have added the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Thanks.

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

Lemme CC him now too, as an FYI.

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

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

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



-- 
Regards/Gruss,
    Boris.

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

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

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


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

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

Hi, FWIW LGTM.

thanks,
-- 
js
suse labs


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

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

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

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

Hi all,

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

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

Caused by commit

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

from the crypto tree interacting with commit

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

from the tip tree.

I have applied the following merge fix patch.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

This patch is now just:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi Ingo,

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

Thanks.
-- 
Cheers,
Stephen Rothwell

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

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

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


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

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

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

Thanks,

	Ingo

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

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

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

Hi all,

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

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

Caused by commit

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

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

I added a commit to reenable execute permissions.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

Hi Ingo,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

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

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

Thanks,

	Ingo

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the drm tree.

I added the following merge fix patch for today:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

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

#define INTEL_FAM6_KABYLAKE_MOBILE INTEL_FAM6_KABYLAKE_L

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

Thanks,

	tglx


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

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

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

ARGHH... rebase again?

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from the sound-asoc tree.

I have added the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

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

Caused by commit

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

I have reverted that commit for today.

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

I have added the following patch for today:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi Ilya,

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

Of course.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi Stephen,

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

Thanks,

                Ilya

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

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

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

Hi all,

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

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the ceph tree.

I have added the following merge fix patch for today.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi David,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi David,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the btrfs-kdave tree.

I have applied the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Thomas Gleixner <tglx@linutronix.de> writes:

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

Good, I'll do that then.

-- 
Kalle Valo

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

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

On Tue, 25 Jun 2019, Stephen Rothwell wrote:

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

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

Thanks,

	tglx

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

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

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

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

Thanks, I'll do that.

> I guess DaveM needs to know, right?

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

-- 
Kalle Valo

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

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

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

Hi Kalle,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

Thanks,

	tglx

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

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

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

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

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

-- 
Kalle Valo

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

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

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

Hi all,

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

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

Caused by commit

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

from the wireless-drivers-next tree interacting with commit

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

from the tip tree.

I have added the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

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

Caused by commit

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

I build with O=

I have appplied the following fix patch for today:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi Stephen,

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

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


Thanks,

	Joerg

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

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

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

Hi all,

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

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

Caused by commit

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

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

Invalid absolute R_386_32 relocation: __end_rodata_aligned

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

A well..

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

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

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

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

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

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

David

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

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

Peter Zijlstra <peterz@infradead.org> wrote:

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

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

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

David

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

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

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

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commits

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

from the net-next tree.

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

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

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

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

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

Thanks,

	Ingo

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

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

Hi Ingo,

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

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

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

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

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

Looks good, thanks Ingo!

-- 
Josh

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

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

Hi Ingo,

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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


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

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

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

Thanks,

	Ingo

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

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

Hi Josh,

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

Yes, thanks.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi Stephen,

Does this fix it?

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

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

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

Hi all,

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

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

Presumably caused by commit

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

-Kees

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



-- 
Kees Cook
Pixel Security

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

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

Hi all,

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

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

and another similar.

Caused by commit

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

from te net-next tree interacting with commit

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

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

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



-- 
Cheers,
Stephen Rothwell

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

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

Hi jeffy,

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

Sure, but that can be done later.

-- 
Cheers,
Stephen Rothwell

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

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

Hi Stephen,

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

thanx for fixing this. and i saw

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

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


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

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

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from Linus' tree.

I have applied the merge fix patch below.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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


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

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

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

Thanks,

	Ingo

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

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

Hi all,

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

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

Caused by commit

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

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

I wasn't sure if just adding

  #define static_key_slow_dec_cpuslocked static_key_slow_dec

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Thanks,
Mikko.

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

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

Hi all,

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

Thanks for the quick response.

-- 
Cheers,
Stephen Rothwell

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

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


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

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

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

Thanks,

	Ingo

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

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

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

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

- Arnaldo
 
> thanks,
> jirka

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

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

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

SNIP

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

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

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

thanks,
jirka

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

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


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

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

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

Which included these build system changes:

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

Thanks,

	Ingo


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

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

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

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

Hi all,

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from the net-next tree.

I have applied the following merge fix patch.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

OK, dropping the hibernation patch for now.

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

Thanks,
Rafael

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

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

Hi,

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

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

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

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

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

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

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

Looks good to me, thanks Stephen!

Rafael

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from the pm tree.

I have applied the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Thanks and sorry about it. Looks fine.

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

-- 
viresh

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

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

Hi all,

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

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

Caused by commit

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

interacting with commit

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

from the pm tree.

I have applied the foloowing build fix for today.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

make ARCH=i386 allnoconfig
make allnoconfig

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

I'll now be using:

make ARCH=i386 allnoconfig
make ARCH=x86_64 allnoconfig

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

Paul.
--

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

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

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

Hi all,

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

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

Probably caused by commit

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

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

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

I have added this patch for today:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

ook ;-)

jirka

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

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

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

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

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

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

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

Hi all,

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

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

Caused by commit

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

I added the following patch for today:

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

thanks,
jirka


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

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

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

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

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

jirka

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Arnaldo

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

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

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

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

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

- Arnaldo

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

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

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

Hi acme,

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

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

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

cheers

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

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

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

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

minimal-ubuntu-x-ppc64el: Ok

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

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

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

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

Hi all,

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

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

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

Presumably caused by commit

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

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

-- 
Cheers,
Stephen Rothwell

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

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


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

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

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

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

Thanks,

	Ingo

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

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

Hi Ingo,

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

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

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

Good, hopefully it is not too hard to fix.

-- 
Cheers,
Stephen Rothwell

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

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

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

Thanks for the clarification.

I talked about my experiences in software building in general.

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

- Sedat -

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

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

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

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

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

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

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

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

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

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

[ EXAMPLE: Linux Kconfig-system ]

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

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

- Sedat -

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

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


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

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

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

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

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

Thanks,

	Ingo

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

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

Hi all,

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

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

and further errors ...

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

Presumably caused by commit

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

and the commit series that was merged.

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

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-30  6:08       ` Jiri Olsa
@ 2015-09-30  6:17         ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-30  6:17 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 30 Sep 2015 08:08:12 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> ouch, forgot to CC you, sry

No worries, I was watching ...

> it won't fix the build if you still have old .cmd file in you tree (I presume that's the case),
> once those are regenerated you shouldn't meet the issue again

Unfortunately this is what happens to me every day :-( (at least until
these changes are merged into Linus' tree).  Its fine, I have automated
the clean up of the perf build object directory after merging the tip
tree.  However, this will also happen to anyone who has built perf then
updates their tree and then tries to rebuild perf.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-30  2:56     ` Stephen Rothwell
@ 2015-09-30  6:08       ` Jiri Olsa
  2015-09-30  6:17         ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Jiri Olsa @ 2015-09-30  6:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 30, 2015 at 12:56:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > > 
> > > > After merging the tip tree, today's linux-next build (perf) failed
> > > > like this:
> > > > 
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > > Makefile:68: recipe for target 'all' failed
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > > > 
> > > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > > the build for each tree merge (in case that matters).
> > > 
> > > it does in this case, removed header files stay in
> > > cmd build dependency file (like in .abspath.o.cmd above)
> > > and cause build error
> > > 
> > > build system is not smart enough yet to find out,
> > > I was postponning fixing this for some time now,
> > > I'll try to get this resolved asap
> > 
> > OK, for now I will clean out my objdir before doing the perf build
> > after the tip tree merge.  It would be nice to have this fixed, though,
> > if possible.
> 
> I noticed some commits in the tip tree today that seemed as though they
> were addressing this problem.  However, I still get a build failure if
> I don't clean out the object directory before building tools/perf:

ouch, forgot to CC you, sry

> 
>   BUILD:   Doing 'make -j48' parallel build
>   GEN      /home/sfr/next/perf/common-cmds.h
>   CC       /home/sfr/next/perf/fixdep.o
>   LD       /home/sfr/next/perf/fixdep-in.o
>   LINK     /home/sfr/next/perf/fixdep
>   CC       /home/sfr/next/perf/perf-read-vdso32
>   CC       /home/sfr/next/perf/perf-read-vdsox32
> make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
> /home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed
> make[2]: *** [ui/gtk] Error 2
> Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

it won't fix the build if you still have old .cmd file in you tree (I presume that's the case),
once those are regenerated you shouldn't meet the issue again

jirka

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-17  0:34   ` Stephen Rothwell
@ 2015-09-30  2:56     ` Stephen Rothwell
  2015-09-30  6:08       ` Jiri Olsa
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-30  2:56 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi all,

On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (perf) failed
> > > like this:
> > > 
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > Makefile:68: recipe for target 'all' failed
> > > 
> > > Maybe caused by commit
> > > 
> > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > > 
> > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > the build for each tree merge (in case that matters).
> > 
> > it does in this case, removed header files stay in
> > cmd build dependency file (like in .abspath.o.cmd above)
> > and cause build error
> > 
> > build system is not smart enough yet to find out,
> > I was postponning fixing this for some time now,
> > I'll try to get this resolved asap
> 
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge.  It would be nice to have this fixed, though,
> if possible.

I noticed some commits in the tip tree today that seemed as though they
were addressing this problem.  However, I still get a build failure if
I don't clean out the object directory before building tools/perf:

  BUILD:   Doing 'make -j48' parallel build
  GEN      /home/sfr/next/perf/common-cmds.h
  CC       /home/sfr/next/perf/fixdep.o
  LD       /home/sfr/next/perf/fixdep-in.o
  LINK     /home/sfr/next/perf/fixdep
  CC       /home/sfr/next/perf/perf-read-vdso32
  CC       /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

(/home/sfr/next/perf/ is the object directory)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:16 ` Jiri Olsa
  2015-09-16  6:38   ` Jiri Olsa
@ 2015-09-17  0:34   ` Stephen Rothwell
  2015-09-30  2:56     ` Stephen Rothwell
  1 sibling, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-17  0:34 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap

OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge.  It would be nice to have this fixed, though,
if possible.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  7:30     ` Stephen Rothwell
@ 2015-09-16 14:17       ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 357+ messages in thread
From: Arnaldo Carvalho de Melo @ 2015-09-16 14:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jiri Olsa, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Jiri Olsa

Em Wed, Sep 16, 2015 at 05:30:25PM +1000, Stephen Rothwell escreveu:
> Hi Jiri,
> 
> On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > > > Also, building perf seems to ignore O=<dir> on the make invocation.
> > > > Is that expected?
> > > 
> > > hum, not sure about this one.. I'm not using it, but we have
> > > tests for this and I thought we're ok.. I'll check
> > 
> > seems to work on latest Arnaldo's perf/core,
> > what command line failed for you?
> > 
> > [jolsa@krava perf]$ make O=/tmp/krava/
> > ...
> > [jolsa@krava perf]$ ll /tmp/krava/perf
> > -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
> 
> Thanks for the hint.  I was using a relative path and starting in the
> top of the kernel tree, so:

> $ cd kernel
> $ mkdir ../perf
> $ make -s -C tools/perf JOBS=24 O=../perf
> 
> put everything in toos/perf (no suprise really)
> 
> I will change my script to use an absolute path (which I checked does
> work fine).  Sorry for the noise.

Nice workaround, but I guess relative paths should be supported as well,
right? :)

- Arnaldo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:38   ` Jiri Olsa
@ 2015-09-16  7:30     ` Stephen Rothwell
  2015-09-16 14:17       ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-16  7:30 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi Jiri,

On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> > > Also, building perf seems to ignore O=<dir> on the make invocation.
> > > Is that expected?
> > 
> > hum, not sure about this one.. I'm not using it, but we have
> > tests for this and I thought we're ok.. I'll check
> 
> seems to work on latest Arnaldo's perf/core,
> what command line failed for you?
> 
> [jolsa@krava perf]$ make O=/tmp/krava/
> ...
> [jolsa@krava perf]$ ll /tmp/krava/perf
> -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf

Thanks for the hint.  I was using a relative path and starting in the
top of the kernel tree, so:

$ cd kernel
$ mkdir ../perf
$ make -s -C tools/perf JOBS=24 O=../perf

put everything in toos/perf (no suprise really)

I will change my script to use an absolute path (which I checked does
work fine).  Sorry for the noise.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  6:16 ` Jiri Olsa
@ 2015-09-16  6:38   ` Jiri Olsa
  2015-09-16  7:30     ` Stephen Rothwell
  2015-09-17  0:34   ` Stephen Rothwell
  1 sibling, 1 reply; 357+ messages in thread
From: Jiri Olsa @ 2015-09-16  6:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
> 
> > 
> > I have used the tip tree from next-20150915 for today.
> > 
> > Also, building perf seems to ignore O=<dir> on the make invocation.
> > Is that expected?
> 
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check

seems to work on latest Arnaldo's perf/core,
what command line failed for you?

[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf


jirka

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  0:12 Stephen Rothwell
@ 2015-09-16  6:16 ` Jiri Olsa
  2015-09-16  6:38   ` Jiri Olsa
  2015-09-17  0:34   ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Jiri Olsa @ 2015-09-16  6:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'arch' failed
> make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'fs' failed
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'util' failed
> Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> Makefile:68: recipe for target 'all' failed
> 
> Maybe caused by commit
> 
>   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")
> 
> This is an incremental build i.e. I do not do a "make clean" after doing
> the build for each tree merge (in case that matters).

it does in this case, removed header files stay in
cmd build dependency file (like in .abspath.o.cmd above)
and cause build error

build system is not smart enough yet to find out,
I was postponning fixing this for some time now,
I'll try to get this resolved asap

> 
> I have used the tip tree from next-20150915 for today.
> 
> Also, building perf seems to ignore O=<dir> on the make invocation.
> Is that expected?

hum, not sure about this one.. I'm not using it, but we have
tests for this and I thought we're ok.. I'll check

jirka

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-09-16  1:30 Stephen Rothwell
@ 2015-09-16  4:53 ` David Miller
  0 siblings, 0 replies; 357+ messages in thread
From: David Miller @ 2015-09-16  4:53 UTC (permalink / raw)
  To: sfr; +Cc: tglx, mingo, hpa, peterz, netdev, linux-next, linux-kernel, oneukum

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks Stephen.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-09-16  1:30 Stephen Rothwell
  2015-09-16  4:53 ` David Miller
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-16  1:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David Miller, netdev
  Cc: linux-next, linux-kernel, Oliver Neukum

Hi all,

After merging the next-20150915 version of the tip tree, today's
linux-next build (x86_64 allmodconfig) failed like this:

In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
                 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
        ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
                 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:44:5: error: conflicting types for 'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
                 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:44:5: note: previous declaration of 'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
     ^

Caused by commit

  c40a2c8817e4 ("CDC: common parser for extra headers")

from the net-next tree that added include/linux/usb/cdc.h with no
reinclusion guards.

I am not sure why I did not see this failure when building after
merging the net-next tree.  Maybe it is exposed by some config change
in the tip tree?

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Sep 2015 11:10:16 +1000
Subject: [PATCH] cdc: add header guards

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/usb/cdc.h      | 4 ++++
 include/uapi/linux/usb/cdc.h | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 959d0c838113..b5706f94ee9e 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -7,6 +7,8 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  */
+#ifndef __LINUX_USB_CDC_H
+#define __LINUX_USB_CDC_H
 
 #include <uapi/linux/usb/cdc.h>
 
@@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 				struct usb_interface *intf,
 				u8 *buffer,
 				int buflen);
+
+#endif /* __LINUX_USB_CDC_H */
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index b6a9cdd6e096..e2bc417b243b 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -6,8 +6,8 @@
  * firmware based USB peripherals.
  */
 
-#ifndef __LINUX_USB_CDC_H
-#define __LINUX_USB_CDC_H
+#ifndef __UAPI_LINUX_USB_CDC_H
+#define __UAPI_LINUX_USB_CDC_H
 
 #include <linux/types.h>
 
@@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size {
 #define USB_CDC_NCM_CRC_NOT_APPENDED			0x00
 #define USB_CDC_NCM_CRC_APPENDED			0x01
 
-#endif /* __LINUX_USB_CDC_H */
+#endif /* __UAPI_LINUX_USB_CDC_H */
-- 
2.5.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-09-16  0:12 Stephen Rothwell
  2015-09-16  6:16 ` Jiri Olsa
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-09-16  0:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jiri Olsa, Arnaldo Carvalho de Melo

Hi all,

After merging the tip tree, today's linux-next build (perf) failed
like this:

make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/arch/common.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'arch' failed
make[4]: *** No rule to make target 'fs/debugfs.h', needed by 'tools/perf/fs/fs.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'fs' failed
make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 'tools/perf/util/abspath.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'util' failed
Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
Makefile:68: recipe for target 'all' failed

Maybe caused by commit

  60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")

This is an incremental build i.e. I do not do a "make clean" after doing
the build for each tree merge (in case that matters).

I have used the tip tree from next-20150915 for today.

Also, building perf seems to ignore O=<dir> on the make invocation.
Is that expected?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28 16:34 ` Luis R. Rodriguez
@ 2015-07-28 18:17   ` Luis R. Rodriguez
  0 siblings, 0 replies; 357+ messages in thread
From: Luis R. Rodriguez @ 2015-07-28 18:17 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, benh
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Tue, Jul 28, 2015 at 06:34:19PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> > drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >   ^
> > drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >                    ^
> > 
> > Caused by commits
> > 
> >   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
> >   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> > 
> > The latter defines ioremap_uc() for x86 and those architectures that
> > use asm-generic/io.h - which is not all of them :-( .  The former commit
> > then uses ioremap_uc().
> > 
> > I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> > for today.
> 
> This should be fixed by:
> 
> http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb
> 
> The way it was defined was to return NULL if an arch does not have it,
> *but* if the asm-generic io.h header is not included on some archs it will still
> fail, which leaves us no option but to then poke and define its implementaiton
> for archs which opt-out of asm-generic io.h
> 
> Benh, in this case I believe its OK to to just map it to ioremap(), let me know
> what you think.
> 

I checked and there are other architectures that do not include asm-generic/io.h,
so here is the full patch fix, which I'll post next.

From: "Luis R. Rodriguez" <mcgrof@suse.com>
Subject: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures

This adds ioremap_uc() only for architectures that do not
include asm-generic.h/io.h as that already provides a default
definition for them for both cases where you have CONFIG_MMU
and you do not, and because of this, the number of architectures
this patch address is less than the architectures that the
ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to all
architectures").

In order to reduce the number of architectures we have to
modify by adding new architecture IO APIs we'll have to review
the architectures in this patch, see why they can't add
asm-generic.h/io.h or issues that would be created by doing
so and then spread a consistent inclusion of this header
towards the end of their own header. For instance arch/metag
includes the asm-generic/io.h *before* the ioremap*()
definitions, this should be the other way around but only
once we have guard wrappers for the non-MMU case also for
asm-generic/io.h.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/avr32/include/asm/io.h   | 1 +
 arch/frv/include/asm/io.h     | 1 +
 arch/m32r/include/asm/io.h    | 1 +
 arch/m68k/include/asm/io_mm.h | 1 +
 arch/mn10300/include/asm/io.h | 1 +
 arch/powerpc/include/asm/io.h | 1 +
 arch/sh/include/asm/io.h      | 1 +
 arch/tile/include/asm/io.h    | 1 +
 8 files changed, 8 insertions(+)

diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index e998ff5d8e1a..f855646e0db7 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -297,6 +297,7 @@ extern void __iounmap(void __iomem *addr);
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index a31b63ec4930..70dfbea8c8d7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -278,6 +278,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned l
 }
 
 #define ioremap_wc ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 extern void iounmap(void volatile __iomem *addr);
 
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index f8de767ce2bc..61b8931bc192 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -69,6 +69,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index f55cad529400..c98ac81582ac 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -468,6 +468,7 @@ static inline void __iomem *ioremap_nocache(unsigned long physaddr, unsigned lon
 {
 	return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
+#define ioremap_uc ioremap_nocache
 static inline void __iomem *ioremap_wt(unsigned long physaddr,
 					 unsigned long size)
 {
diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index 07c5b4a3903b..62189353d2f6 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -283,6 +283,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 static inline void iounmap(void __iomem *addr)
 {
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..5879fde56f3c 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
 				  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)	ioremap((addr), (size))
+#define ioremap_uc(addr, size)		ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 728c4c571f40..93ec9066dbef 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -368,6 +368,7 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; }
 #endif
 
 #define ioremap_nocache	ioremap
+#define ioremap_uc	ioremap
 #define iounmap		__iounmap
 
 /*
diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index dc61de15c1f9..322b5fe94781 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -55,6 +55,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_wc(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_wt(physaddr, size)		ioremap(physaddr, size)
+#define ioremap_uc(physaddr, size)		ioremap(physaddr, size)
 #define ioremap_fullcache(physaddr, size)	ioremap(physaddr, size)
 
 #define mmiowb()
-- 
2.3.2.209.gd67f9d5.dirty

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  5:33 Stephen Rothwell
@ 2015-07-28 16:34 ` Luis R. Rodriguez
  2015-07-28 18:17   ` Luis R. Rodriguez
  0 siblings, 1 reply; 357+ messages in thread
From: Luis R. Rodriguez @ 2015-07-28 16:34 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, benh
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>   ^
> drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>                    ^
> 
> Caused by commits
> 
>   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
>   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> 
> The latter defines ioremap_uc() for x86 and those architectures that
> use asm-generic/io.h - which is not all of them :-( .  The former commit
> then uses ioremap_uc().
> 
> I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> for today.

This should be fixed by:

http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb

The way it was defined was to return NULL if an arch does not have it,
*but* if the asm-generic io.h header is not included on some archs it will still
fail, which leaves us no option but to then poke and define its implementaiton
for archs which opt-out of asm-generic io.h

Benh, in this case I believe its OK to to just map it to ioremap(), let me know
what you think.

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..91db9153cd44 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
 				  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)	ioremap((addr), (size))
+#define ioremap_uc(addr, size)	ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 

  Luis

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  8:41 ` Sudeep Holla
@ 2015-07-28  9:43   ` Gregory CLEMENT
  0 siblings, 0 replies; 357+ messages in thread
From: Gregory CLEMENT @ 2015-07-28  9:43 UTC (permalink / raw)
  To: Sudeep Holla, Stephen Rothwell
  Cc: linux-arm-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Jason Cooper, andrew, linux-next, linux-kernel,
	Thomas Petazzoni

Hi Sudeep, Stephen,

On 28/07/2015 10:41, Sudeep Holla wrote:
> Hi Stephen,
> 
> On 28/07/15 03:43, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
>> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
>>     gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
>>     ^
>>
>> Caused by commit
>>
>>    e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")
>>
>> from the mvebu tree interacting with commit
>>
>>    0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
>>
>> from the tip tree.
>>
>> I have applied the following merge fix patch for today:
>>
> 
> Thanks for the fix, I was aware of this and asked Thomas Petazzoni
> and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
> yesterday [1]
> 

I've just remove the commit from my branches, it should be OK now.


Thanks,

Gregory


> Regards,
> Sudeep
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-28  2:43 Stephen Rothwell
@ 2015-07-28  8:41 ` Sudeep Holla
  2015-07-28  9:43   ` Gregory CLEMENT
  0 siblings, 1 reply; 357+ messages in thread
From: Sudeep Holla @ 2015-07-28  8:41 UTC (permalink / raw)
  To: Stephen Rothwell, gregory.clement, linux-arm-kernel
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Jason Cooper, andrew, Sudeep Holla, linux-next, linux-kernel,
	Thomas Petazzoni

Hi Stephen,

On 28/07/15 03:43, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
>     gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
>     ^
>
> Caused by commit
>
>    e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")
>
> from the mvebu tree interacting with commit
>
>    0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
>
> from the tip tree.
>
> I have applied the following merge fix patch for today:
>

Thanks for the fix, I was aware of this and asked Thomas Petazzoni
and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
yesterday [1]

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-28  5:33 Stephen Rothwell
  2015-07-28 16:34 ` Luis R. Rodriguez
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-07-28  5:33 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Luis R. Rodriguez

Hi all,

After merging the tip tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of function 'ioremap_uc' [-Werror=implicit-function-declaration]
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
  ^
drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer from integer without a cast
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
                   ^

Caused by commits

  3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC")
  8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")

The latter defines ioremap_uc() for x86 and those architectures that
use asm-generic/io.h - which is not all of them :-( .  The former commit
then uses ioremap_uc().

I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-28  2:43 Stephen Rothwell
  2015-07-28  8:41 ` Sudeep Holla
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-07-28  2:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Jason Cooper, andrew, gregory.clement, linux-arm-kernel
  Cc: linux-next, linux-kernel, Sudeep Holla

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
   ^

Caused by commit

  e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")

from the mvebu tree interacting with commit

  0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")

from the tip tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Jul 2015 12:26:21 +1000
Subject: [PATCH] irqchip/gic: merge fix for "Remove redundant gic_set_irqchip_flags"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mach-mvebu/board-v7.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a6d2b4d6701a..b5ef80f369e7 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
 
 static void __init mvebu_init_irq(void)
 {
-	struct device_node *np;
-
-	np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-gic");
-	if (np)
-		gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
-				      IRQCHIP_MASK_ON_SUSPEND);
-	of_node_put(np);
 	irqchip_init();
 	mvebu_scu_enable();
 	coherency_init();
-- 
2.4.6

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-15  1:01 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-07-15  1:01 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Julia Lawall, Jiang Liu, Linus Walleij,
	linux-gpio

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pinctrl/sirf/pinctrl-atlas7.c: In function 'atlas7_gpio_handle_irq':
drivers/pinctrl/sirf/pinctrl-atlas7.c:4300:20: error: 'irq' undeclared (first use in this function)
   if (bank->irq == irq)
                    ^

Caused by commit

  5dc1aeb0340f ("pinctrl/sirf: Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch")
[hmmm, not a wonderful commit summary line]

I tried to use the tip tree from next-20150714, but for some reason that
broke the perf build:

  BUILD:   Doing 'make -j48' parallel build
make[3]: *** No rule to make target '../lib/hweight.c', needed by '/scratch/sfr/next/tools/perf/util/hweight.o'.  Stop.

So instead, I applied the following fix patch for today's issue:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 15 Jul 2015 10:56:28 +1000
Subject: [PATCH] pinctrl/sirf: fix for Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index f55c931f1088..7917b7719939 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -4294,6 +4294,7 @@ static void atlas7_gpio_handle_irq(unsigned int __irq, struct irq_desc *desc)
 	u32 status, ctrl;
 	int pin_in_bank = 0, idx;
 	struct irq_chip *chip = irq_desc_get_chip(desc);
+	unsigned int irq = irq_desc_get_irq(desc);
 
 	for (idx = 0; idx < a7gc->nbank; idx++) {
 		bank = &a7gc->banks[idx];
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-07-08  0:56 Stephen Rothwell
@ 2015-07-08  9:40 ` Thomas Gleixner
  0 siblings, 0 replies; 357+ messages in thread
From: Thomas Gleixner @ 2015-07-08  9:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

On Wed, 8 Jul 2015, Stephen Rothwell wrote:
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/cpu.c: In function '_cpu_down':
> kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration]
>   irq_lock_sparse();
>   ^
> kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
>    irq_unlock_sparse();
>    ^
> 
> Caused by commit
> 
>   fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down")
> 
> Forgot to include linux/irqdesc.h.
> 
> I have used the tip tree from next-20150707 for today.

Fixed in tip. Sorry for the hickup.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-07-08  0:56 Stephen Rothwell
  2015-07-08  9:40 ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-07-08  0:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

kernel/cpu.c: In function '_cpu_down':
kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' [-Werror=implicit-function-declaration]
  irq_lock_sparse();
  ^
kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
   irq_unlock_sparse();
   ^

Caused by commit

  fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down")

Forgot to include linux/irqdesc.h.

I have used the tip tree from next-20150707 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* RE: linux-next: build failure after merge of the tip tree
  2015-06-12 21:22   ` David Miller
@ 2015-06-12 21:25     ` Chickles, Derek
  0 siblings, 0 replies; 357+ messages in thread
From: Chickles, Derek @ 2015-06-12 21:25 UTC (permalink / raw)
  To: David Miller
  Cc: mpe, tglx, mingo, hpa, peterz, linux-next, linux-kernel, sfr,
	Burla, Satananda, Manlunas, Felix, Richter, Robert, Makarov,
	Aleksey, Vatsavayi, Raghu



> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
>  ...
> > Thanks. Much appreciated.
> 
> This doesn't work, neither of these emails are a formal proper submission
> of a fix for this build failure.
> 
> One of you has to do the work to formally submit the patch to netdev
> with a full signoff and commit log message so that it gets fixed in my
> tree.
> 
> Thanks.

Yes, we're working on this. Hopefully, we'll have this submitted later today, with the build fix and sparse warning fixes.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
       [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
@ 2015-06-12 21:22   ` David Miller
  2015-06-12 21:25     ` Chickles, Derek
  0 siblings, 1 reply; 357+ messages in thread
From: David Miller @ 2015-06-12 21:22 UTC (permalink / raw)
  To: Derek.Chickles
  Cc: mpe, tglx, mingo, hpa, peterz, linux-next, linux-kernel, sfr,
	Satananda.Burla, Felix.Manlunas, Robert.Richter, Aleksey.Makarov,
	Raghu.Vatsavayi

From: "Chickles, Derek" <Derek.Chickles@caviumnetworks.com>
Date: Fri, 12 Jun 2015 15:59:54 +0000

>> -----Original Message-----
>> From: Michael Ellerman [mailto:mpe@ellerman.id.au]
>> Sent: Friday, June 12, 2015 3:51 AM
>> To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; David
>> S.Miller
>> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org;
>> sfr@canb.auug.org.au; Chickles, Derek; Burla, Satananda; Manlunas, Felix;
>> Richter, Robert; Makarov, Aleksey; Vatsavayi, Raghu
>> Subject: linux-next: build failure after merge of the tip tree
>> 
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (x86_allmodconfig)
>> failed like this:
 ...
>> And so on.
>> 
>> Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
>> <linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit
>> f21fb3ed364b
>> "Add support of Cavium Liquidio ethernet adapters" from the net-next tree.
>> 
>> I applied the following fix for today:
 ...
> Thanks. Much appreciated.

This doesn't work, neither of these emails are a formal proper submission
of a fix for this build failure.

One of you has to do the work to formally submit the patch to netdev
with a full signoff and commit log message so that it gets fixed in my
tree.

Thanks.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-06-12 10:51 Michael Ellerman
       [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
  0 siblings, 1 reply; 357+ messages in thread
From: Michael Ellerman @ 2015-06-12 10:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	David S.Miller
  Cc: linux-next, linux-kernel, sfr, derek.chickles, satananda.burla,
	felix.manlunas, Robert.Richter, Aleksey.Makarov, raghu.vatsavayi

Hi all,

After merging the tip tree, today's linux-next build (x86_allmodconfig)
failed like this:

  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_init_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:111:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
    iq->request_list = vmalloc(sizeof(*iq->request_list) * num_descs);
    ^
  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'octeon_delete_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:178:3: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
     vfree(iq->request_list);
     ^
  drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 'octeon_free_device_mem':
  drivers/net/ethernet/cavium/liquidio/octeon_device.c:653:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
      vfree(oct->droq[i]);
      ^

And so on.

Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
<linux/vmalloc.h> from <asm/io.h>" from the tip tree with commit f21fb3ed364b
"Add support of Cavium Liquidio ethernet adapters" from the net-next tree.

I applied the following fix for today:

diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 2ca91657295f..4e581facae2c 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -27,6 +27,7 @@
 #include <linux/crc32.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index 60a186f1609b..94b502a0cf33 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -25,6 +25,7 @@
 #include <linux/pci.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index adb428463495..cd58660dd161 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -26,6 +26,7 @@
 #include <linux/pci.h>
 #include <linux/kthread.h>
 #include <linux/netdevice.h>
+#include <linux/vmalloc.h>
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"


cheers

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-06-09  7:15 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-06-09  7:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/kernel.h:13:0,
                 from include/linux/interrupt.h:5,
                 from drivers/iommu/intel_irq_remapping.c:4:
drivers/iommu/intel_irq_remapping.c: In function 'intel_enable_irq_remapping':
drivers/iommu/intel_irq_remapping.c:656:48: error: 'eim' undeclared (first use in this function)
  pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
                                                ^

Caused by my mismerge :-(

I added this merge fix patch (and will fix the merge itself tomorrow):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jun 2015 17:12:00 +1000
Subject: [PATCH] iommu.vt-d: fix mismerge

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/iommu/intel_irq_remapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
index 0d2500d17a2f..c19918471b3a 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -653,7 +653,7 @@ static int __init intel_enable_irq_remapping(void)
 
 	irq_remapping_enabled = 1;
 
-	pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
+	pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic");
 
 	return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-08  5:03             ` Stephen Rothwell
@ 2015-04-15  1:25               ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-04-15  1:25 UTC (permalink / raw)
  To: Daniel Borkmann, davem
  Cc: Alexei Starovoitov, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Steven Rostedt, Masami Hiramatsu, netdev

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

Hi all,

On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> > >> [ Cc'ing Dave, fyi ]
> > >>
> > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> > >>> <daniel@iogearbox.net> wrote:
> > >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >>>>>
> > >>>>>> After merging the tip tree, today's linux-next build (powerpc
> > >>>>>> ppc64_defconfig) failed like this:
> > >>>>>>
> > >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> > >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> > >>>>>> member named 'prog_type'
> > >>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>>>>                  ^
> > >>>>>>
> > >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> > >>>>>> attached to kprobes").
> > >>>>>
> > >>>>> Note, this must be some (rarely triggered) aspect of the ppc64
> > >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
> > >>>>> expose?
> > >>>>
> > >>>> Note, this is a merge conflict with the work that went via net-next
> > >>>> tree,
> > >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> > >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> > >>>>
> > >>>> You should be able to resolve it in linux-next by changing the test to:
> > >>>>
> > >>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>
> > >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> > >>> to tell Linus.
> > >>
> > >> Yes, indeed, depending which tree is merged first.
> > >
> > > Daniel analysis is correct, but the fix for kernel/events/core.c
> > > should be:
> > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > > instead of 'prog->prog_type'
> > 
> > Yes, absolutely, thanks!
> 
> So I have applied that as a merge fix patch.

This patch is now needed when the net-next tree is merged with Linus'
tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 15:08       ` Russell King - ARM Linux
  2015-03-30 15:24         ` Nathan Lynch
@ 2015-04-13 23:34         ` Stephen Rothwell
  1 sibling, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-04-13 23:34 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Nathan Lynch, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Hi Russell,

On Mon, 30 Mar 2015 16:08:38 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> > On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > > Hi Russell,
> > > 
> > > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > >>
> > >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> > >> it in my tree and keep my tree buildable without dragging in the tip
> > >> tree.
> > > 
> > > Does it affect your tree on its own?  If not, then it can be fixed when
> > > merged as I have done, or if you look at the tip tree, all you really
> > > need to merge is tip timers/core branch (which I am sure the tip guys
> > > can tell you if it is stable enough) which is about 28 commits ...
> > > 
> > >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > > 
> > > If that works for you.
> > 
> > FWIW, Stephen's merge fix is correct and I have run my vdso tests
> > without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

This patch is now needed when the arm tree is merged with Linus' tree
(the tip tree part has been merged).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 19:54           ` Daniel Borkmann
@ 2015-04-08  5:03             ` Stephen Rothwell
  2015-04-15  1:25               ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-04-08  5:03 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Alexei Starovoitov, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Steven Rostedt, Masami Hiramatsu, davem

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

Hi all,

On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> >> [ Cc'ing Dave, fyi ]
> >>
> >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> >>> <daniel@iogearbox.net> wrote:
> >>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> >>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>>>
> >>>>>> After merging the tip tree, today's linux-next build (powerpc
> >>>>>> ppc64_defconfig) failed like this:
> >>>>>>
> >>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> >>>>>> member named 'prog_type'
> >>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>>>>                  ^
> >>>>>>
> >>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >>>>>> attached to kprobes").
> >>>>>
> >>>>> Note, this must be some (rarely triggered) aspect of the ppc64
> >>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
> >>>>> expose?
> >>>>
> >>>> Note, this is a merge conflict with the work that went via net-next
> >>>> tree,
> >>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> >>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> >>>>
> >>>> You should be able to resolve it in linux-next by changing the test to:
> >>>>
> >>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>
> >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> >>> to tell Linus.
> >>
> >> Yes, indeed, depending which tree is merged first.
> >
> > Daniel analysis is correct, but the fix for kernel/events/core.c
> > should be:
> > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > instead of 'prog->prog_type'
> 
> Yes, absolutely, thanks!

So I have applied that as a merge fix patch.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 16:18         ` Alexei Starovoitov
@ 2015-04-07 19:54           ` Daniel Borkmann
  2015-04-08  5:03             ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Daniel Borkmann @ 2015-04-07 19:54 UTC (permalink / raw)
  To: Alexei Starovoitov, Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Steven Rostedt,
	Masami Hiramatsu, davem

On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> On 4/7/15 4:13 AM, Daniel Borkmann wrote:
>> [ Cc'ing Dave, fyi ]
>>
>> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>>> <daniel@iogearbox.net> wrote:
>>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>
>>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>>> ppc64_defconfig) failed like this:
>>>>>>
>>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>>> member named 'prog_type'
>>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>>>                  ^
>>>>>>
>>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>>> attached to kprobes").
>>>>>
>>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>>> expose?
>>>>
>>>> Note, this is a merge conflict with the work that went via net-next
>>>> tree,
>>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>>
>>>> You should be able to resolve it in linux-next by changing the test to:
>>>>
>>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>
>>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
>>> to tell Linus.
>>
>> Yes, indeed, depending which tree is merged first.
>
> Daniel analysis is correct, but the fix for kernel/events/core.c
> should be:
> - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> instead of 'prog->prog_type'

Yes, absolutely, thanks!

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07 11:13       ` Daniel Borkmann
@ 2015-04-07 16:18         ` Alexei Starovoitov
  2015-04-07 19:54           ` Daniel Borkmann
  0 siblings, 1 reply; 357+ messages in thread
From: Alexei Starovoitov @ 2015-04-07 16:18 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Steven Rostedt,
	Masami Hiramatsu, davem

On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> [ Cc'ing Dave, fyi ]
>
> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
>> <daniel@iogearbox.net> wrote:
>>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>>> After merging the tip tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
>>>>> member named 'prog_type'
>>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>>                  ^
>>>>>
>>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>>> attached to kprobes").
>>>>
>>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>>> expose?
>>>
>>> Note, this is a merge conflict with the work that went via net-next
>>> tree,
>>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>>
>>> You should be able to resolve it in linux-next by changing the test to:
>>>
>>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>>
>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
>> to tell Linus.
>
> Yes, indeed, depending which tree is merged first.

Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog->prog_type'

Thanks Stephen!

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  9:05     ` Stephen Rothwell
@ 2015-04-07 11:13       ` Daniel Borkmann
  2015-04-07 16:18         ` Alexei Starovoitov
  0 siblings, 1 reply; 357+ messages in thread
From: Daniel Borkmann @ 2015-04-07 11:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alexei Starovoitov,
	Steven Rostedt, Masami Hiramatsu, davem

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> After merging the tip tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) failed like this:
>>>>
>>>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>>>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>>>>     if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>>>                  ^
>>>>
>>>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>>>> attached to kprobes").
>>>
>>> Note, this must be some (rarely triggered) aspect of the ppc64
>>> defconfig that neither x86 randconfigs nor most other arch defconfigs
>>> expose?
>>
>> Note, this is a merge conflict with the work that went via net-next tree,
>> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>>
>> You should be able to resolve it in linux-next by changing the test to:
>>
>>     if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
>
> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> to tell Linus.

Yes, indeed, depending which tree is merged first.

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  8:56   ` Daniel Borkmann
@ 2015-04-07  9:05     ` Stephen Rothwell
  2015-04-07 11:13       ` Daniel Borkmann
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-04-07  9:05 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alexei Starovoitov,
	Steven Rostedt, Masami Hiramatsu

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

Hi Daniel,

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> After merging the tip tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
> >>    if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>                 ^
> >>
> >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >> attached to kprobes").
> >
> > Note, this must be some (rarely triggered) aspect of the ppc64
> > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > expose?
> 
> Note, this is a merge conflict with the work that went via net-next tree,
> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> 
> You should be able to resolve it in linux-next by changing the test to:
> 
>    if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  8:48 ` Ingo Molnar
@ 2015-04-07  8:56   ` Daniel Borkmann
  2015-04-07  9:05     ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Daniel Borkmann @ 2015-04-07  8:56 UTC (permalink / raw)
  To: Ingo Molnar, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

On 04/07/2015 10:48 AM, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
>> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>>    if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>>                 ^
>>
>> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
>> attached to kprobes").
>
> Note, this must be some (rarely triggered) aspect of the ppc64
> defconfig that neither x86 randconfigs nor most other arch defconfigs
> expose?

Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

   if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  7:18 Stephen Rothwell
  2015-04-07  8:48 ` Ingo Molnar
@ 2015-04-07  8:53 ` Peter Zijlstra
  1 sibling, 0 replies; 357+ messages in thread
From: Peter Zijlstra @ 2015-04-07  8:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
	linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

On Tue, Apr 07, 2015 at 05:18:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>                ^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").
> 
> I have used the tip tree from next-20150402 for today.

Hmm, tip/master builds fine on ppc64 for me, but does something like the
below help?

---
Subject: perf: Fix BPF filter crud

The BPF filter crud got its CONFIG deps wrong, fix it.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/events/core.c |   37 ++++++++++++++++++++++---------------
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 06917d5..1d94b92 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6711,6 +6711,25 @@ static void perf_event_free_filter(struct perf_event *event)
 	ftrace_profile_free_filter(event);
 }
 
+#else /* EVENT_TRACING */
+
+static inline void perf_tp_register(void)
+{
+}
+
+static int perf_event_set_filter(struct perf_event *event, void __user *arg)
+{
+	return -ENOENT;
+}
+
+static void perf_event_free_filter(struct perf_event *event)
+{
+}
+
+#endif /* EVENT_TRACING */
+
+#if defined CONFIG_BPF_EVENTS && defined CONFIG_EVENT_TRACING
+
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
 	struct bpf_prog *prog;
@@ -6754,20 +6773,7 @@ static void perf_event_free_bpf_prog(struct perf_event *event)
 	}
 }
 
-#else
-
-static inline void perf_tp_register(void)
-{
-}
-
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-	return -ENOENT;
-}
-
-static void perf_event_free_filter(struct perf_event *event)
-{
-}
+#else /* BPF_EVENTS && EVENT_TRACING */
 
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
@@ -6777,7 +6783,8 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 static void perf_event_free_bpf_prog(struct perf_event *event)
 {
 }
-#endif /* CONFIG_EVENT_TRACING */
+
+#endif /* BPF_EVENTS && EVENT_TRACING */
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
 void perf_bp_event(struct perf_event *bp, void *data)

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-04-07  7:18 Stephen Rothwell
@ 2015-04-07  8:48 ` Ingo Molnar
  2015-04-07  8:56   ` Daniel Borkmann
  2015-04-07  8:53 ` Peter Zijlstra
  1 sibling, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2015-04-07  8:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>                ^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").

Note, this must be some (rarely triggered) aspect of the ppc64 
defconfig that neither x86 randconfigs nor most other arch defconfigs 
expose?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-04-07  7:18 Stephen Rothwell
  2015-04-07  8:48 ` Ingo Molnar
  2015-04-07  8:53 ` Peter Zijlstra
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2015-04-07  7:18 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Alexei Starovoitov, Steven Rostedt,
	Masami Hiramatsu

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 'prog_type'
  if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
               ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").

I have used the tip tree from next-20150402 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 15:08       ` Russell King - ARM Linux
@ 2015-03-30 15:24         ` Nathan Lynch
  2015-04-13 23:34         ` Stephen Rothwell
  1 sibling, 0 replies; 357+ messages in thread
From: Nathan Lynch @ 2015-03-30 15:24 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
>> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
>>> Hi Russell,
>>>
>>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>>>
>>>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>>>> it in my tree and keep my tree buildable without dragging in the tip
>>>> tree.
>>>
>>> Does it affect your tree on its own?  If not, then it can be fixed when
>>> merged as I have done, or if you look at the tip tree, all you really
>>> need to merge is tip timers/core branch (which I am sure the tip guys
>>> can tell you if it is stable enough) which is about 28 commits ...
>>>
>>>> The ARM VDSO stuff will just have to wait for 4.2 instead.
>>>
>>> If that works for you.
>>
>> FWIW, Stephen's merge fix is correct and I have run my vdso tests
>> without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

OK, let me know if I can help.

I'm happy to remind you about it when the merge window opens.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30 14:57     ` Nathan Lynch
@ 2015-03-30 15:08       ` Russell King - ARM Linux
  2015-03-30 15:24         ` Nathan Lynch
  2015-04-13 23:34         ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Russell King - ARM Linux @ 2015-03-30 15:08 UTC (permalink / raw)
  To: Nathan Lynch
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > Hi Russell,
> > 
> > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >>
> >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> >> it in my tree and keep my tree buildable without dragging in the tip
> >> tree.
> > 
> > Does it affect your tree on its own?  If not, then it can be fixed when
> > merged as I have done, or if you look at the tip tree, all you really
> > need to merge is tip timers/core branch (which I am sure the tip guys
> > can tell you if it is stable enough) which is about 28 commits ...
> > 
> >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > 
> > If that works for you.
> 
> FWIW, Stephen's merge fix is correct and I have run my vdso tests
> without problems on OMAP5 with next-20150330.

Hopefully, I can pull the tip stuff but if not, I'll try to remember
to include Stephen's patch with my pull request, but I can't make any
guarantees - Stephen's email will very quickly get buried in my mailbox,
and I'll most likely forget about it too... I'm notoriously bad with
email...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  8:08   ` Stephen Rothwell
@ 2015-03-30 14:57     ` Nathan Lynch
  2015-03-30 15:08       ` Russell King - ARM Linux
  0 siblings, 1 reply; 357+ messages in thread
From: Nathan Lynch @ 2015-03-30 14:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Russell King - ARM Linux, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> Hi Russell,
> 
> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>
>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>> it in my tree and keep my tree buildable without dragging in the tip
>> tree.
> 
> Does it affect your tree on its own?  If not, then it can be fixed when
> merged as I have done, or if you look at the tip tree, all you really
> need to merge is tip timers/core branch (which I am sure the tip guys
> can tell you if it is stable enough) which is about 28 commits ...
> 
>> The ARM VDSO stuff will just have to wait for 4.2 instead.
> 
> If that works for you.

FWIW, Stephen's merge fix is correct and I have run my vdso tests
without problems on OMAP5 with next-20150330.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  7:15 ` Russell King - ARM Linux
@ 2015-03-30  8:08   ` Stephen Rothwell
  2015-03-30 14:57     ` Nathan Lynch
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-03-30  8:08 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nathan Lynch

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

Hi Russell,

On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> it in my tree and keep my tree buildable without dragging in the tip
> tree.

Does it affect your tree on its own?  If not, then it can be fixed when
merged as I have done, or if you look at the tip tree, all you really
need to merge is tip timers/core branch (which I am sure the tip guys
can tell you if it is stable enough) which is about 28 commits ...

> The ARM VDSO stuff will just have to wait for 4.2 instead.

If that works for you.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2015-03-30  6:13 Stephen Rothwell
@ 2015-03-30  7:15 ` Russell King - ARM Linux
  2015-03-30  8:08   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Russell King - ARM Linux @ 2015-03-30  7:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nathan Lynch

On Mon, Mar 30, 2015 at 05:13:34PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
> arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr'
>   if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
>                ^
> arch/arm/kernel/vdso.c: In function 'update_vsyscall':
> arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_cycle_last = tk->tkr.cycle_last;
>                                 ^
> arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
>                                     ^
> arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_mult  = tk->tkr.mult;
>                            ^
> arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_shift  = tk->tkr.shift;
>                             ^
> arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr'
>    vdso_data->cs_mask  = tk->tkr.mask;
>                            ^
> 
> Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
> timekeeper::tkr_mono") from the tip tree interacting with commit
> ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
> synchronization") from the arm tree.
> 
> I added this merge fix patch for today (is that all that is needed?):

I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
tree.

The ARM VDSO stuff will just have to wait for 4.2 instead.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2015-03-30  6:13 Stephen Rothwell
  2015-03-30  7:15 ` Russell King - ARM Linux
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2015-03-30  6:13 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Russell King
  Cc: linux-next, linux-kernel, Nathan Lynch

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member named 'tkr'
  if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
               ^
arch/arm/kernel/vdso.c: In function 'update_vsyscall':
arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_cycle_last = tk->tkr.cycle_last;
                                ^
arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
                                    ^
arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_mult  = tk->tkr.mult;
                           ^
arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_shift  = tk->tkr.shift;
                            ^
arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 'tkr'
   vdso_data->cs_mask  = tk->tkr.mask;
                           ^

Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
timekeeper::tkr_mono") from the tip tree interacting with commit
ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
synchronization") from the arm tree.

I added this merge fix patch for today (is that all that is needed?):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Mar 2015 17:08:21 +1100
Subject: [PATCH] ARM: VDSO: rename tkr to tkr_mono

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/kernel/vdso.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 0d31d3ccab81..efe17dd9b921 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
 	if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
 		return false;
 
-	if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
+	if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
 		return false;
 
 	return true;
@@ -316,12 +316,12 @@ void update_vsyscall(struct timekeeper *tk)
 	vdso_data->wtm_clock_nsec		= wtm->tv_nsec;
 
 	if (vdso_data->tk_is_cntvct) {
-		vdso_data->cs_cycle_last	= tk->tkr.cycle_last;
+		vdso_data->cs_cycle_last	= tk->tkr_mono.cycle_last;
 		vdso_data->xtime_clock_sec	= tk->xtime_sec;
-		vdso_data->xtime_clock_snsec	= tk->tkr.xtime_nsec;
-		vdso_data->cs_mult		= tk->tkr.mult;
-		vdso_data->cs_shift		= tk->tkr.shift;
-		vdso_data->cs_mask		= tk->tkr.mask;
+		vdso_data->xtime_clock_snsec	= tk->tkr_mono.xtime_nsec;
+		vdso_data->cs_mult		= tk->tkr_mono.mult;
+		vdso_data->cs_shift		= tk->tkr_mono.shift;
+		vdso_data->cs_mask		= tk->tkr_mono.mask;
 	}
 
 	vdso_write_end(vdso_data);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-07-29 23:56 ` Stephen Rothwell
@ 2014-07-30  3:10   ` John Stultz
  0 siblings, 0 replies; 357+ messages in thread
From: John Stultz @ 2014-07-30  3:10 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel

On 07/29/2014 04:56 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> arch/powerpc/kernel/time.c:743:6: error: conflicting types for
'update_vsyscall_old'
>>  void update_vsyscall_old(struct timespec *wall_time, struct timespec
*wtm,
>>       ^
>> In file included from arch/powerpc/kernel/time.c:77:0:
>> include/linux/timekeeper_internal.h:114:13: note: previous
declaration of 'update_vsyscall_old' was here
>>  extern void update_vsyscall_old(struct timespec *ts, struct timespec
*wtm,
>>              ^
>>
>> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
>>
>> I have used the tip tree from next-20140724 for today.
>
> Ping?
So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo
in update_vsyscall_old definition), but I've not heard anything from
anyone on it.


thanks
-john

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-07-25  4:45 Stephen Rothwell
@ 2014-07-29 23:56 ` Stephen Rothwell
  2014-07-30  3:10   ` John Stultz
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-07-29 23:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hi all,

On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old'
>  void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
>       ^
> In file included from arch/powerpc/kernel/time.c:77:0:
> include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here
>  extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
>              ^
> 
> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
> 
> I have used the tip tree from next-20140724 for today.

Ping?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-07-25  4:45 Stephen Rothwell
  2014-07-29 23:56 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-07-25  4:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kernel/time.c:743:6: error: conflicting types for 'update_vsyscall_old'
 void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
      ^
In file included from arch/powerpc/kernel/time.c:77:0:
include/linux/timekeeper_internal.h:114:13: note: previous declaration of 'update_vsyscall_old' was here
 extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
             ^

Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").

I have used the tip tree from next-20140724 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 16:23   ` Olof Johansson
@ 2014-06-04 20:02     ` Thomas Gleixner
  0 siblings, 0 replies; 357+ messages in thread
From: Thomas Gleixner @ 2014-06-04 20:02 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Linus Torvalds

On Wed, 4 Jun 2014, Olof Johansson wrote:
> On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> So, we'll dial back and stop taking these patches through our tree
> without an explicit ack or shared branch from you (or Daniel on
> clocksource). Not a problem at all.

I prefer the shared branch (for clocksource and irqchip) either from
me or from Daniel(clocksource) / Jason (irqchip).

That way you can proceed and we can do our unrelated changes without
creating merge dependencies.

> On the other hand, it would have been a lot easier
> to handle had the code on your end landed a bit sooner than in the
> middle of the merge window.

I know. I was just burried in futex wreckage for almost a week...

> Not much I can say besides what's above and that I owe you a few beers
> at the next conference.

Don't worry. I let off steam and all is good if we can avoid this in
the future. Though I'm certainly up for a few beers :)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 10:49 ` Thomas Gleixner
  2014-06-04 14:46   ` Linus Torvalds
@ 2014-06-04 16:23   ` Olof Johansson
  2014-06-04 20:02     ` Thomas Gleixner
  1 sibling, 1 reply; 357+ messages in thread
From: Olof Johansson @ 2014-06-04 16:23 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Linus Torvalds

On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 4 Jun 2014, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>>
>> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
>> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
>>
>> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
>> setup_sched_clock() API") from the tip tree.  The usage was only added
>> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
>> source for Versatile Express") (but this commit has been in linux-next
>> since May 22 at least).
>>
>> I have reverted the tip tree commit for today.
>
> Dammit. Why the heck can ARM folks not route their stuff through the
> relevant maintainers? Because ARM is a different universe with
> different rules or what?

We talked about this as late as February this year. It's has been a
long-standing issue that we've struggled with how we should manage.

When I talked to you about it (irqchip drivers at the time), you said
you were in general fine with us merging driver patches when someone
times out waiting on you to review/merge a patch. My concern at the
time is that while we can look at the code of the patch and review
that, we don't have the larger picture of what's going on in the
subsystem. Which is what caused problems here, I'd say.

So, we'll dial back and stop taking these patches through our tree
without an explicit ack or shared branch from you (or Daniel on
clocksource). Not a problem at all.

> Of course this crap is already in Linus next branch, so it essentially
> blocks me from sending my pending timers/core branch.

We obviously never intended to cause any problems like these, and I
apologize for that. On the other hand, it would have been a lot easier
to handle had the code on your end landed a bit sooner than in the
middle of the merge window.

> Patch below. Linus, can you please apply this?
>
> I've ranted about this before. It's not the first time that ARM breaks
> stuff I maintain.
>
> Again: Send your stuff against drivers/clocksource and drivers/irqchip
> to the maintainers.
>
> I'm happy to provide you a separate branch to pull that stuff from me,
> if you have dependencies on that, but I really don't want to see any
> of this again, ever.
>
> Yours seriously grumpy

Not much I can say besides what's above and that I owe you a few beers
at the next conference.


-Olof

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04 10:49 ` Thomas Gleixner
@ 2014-06-04 14:46   ` Linus Torvalds
  2014-06-04 16:23   ` Olof Johansson
  1 sibling, 0 replies; 357+ messages in thread
From: Linus Torvalds @ 2014-06-04 14:46 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, LKML, Pawel Moll, Stephen Boyd, John Stultz,
	Olof Johansson

On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Patch below. Linus, can you please apply this?

Done.

           Linus

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-06-04  6:05 Stephen Rothwell
@ 2014-06-04 10:49 ` Thomas Gleixner
  2014-06-04 14:46   ` Linus Torvalds
  2014-06-04 16:23   ` Olof Johansson
  0 siblings, 2 replies; 357+ messages in thread
From: Thomas Gleixner @ 2014-06-04 10:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next, LKML,
	Pawel Moll, Stephen Boyd, John Stultz, Olof Johansson,
	Linus Torvalds

On Wed, 4 Jun 2014, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> 
> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
> 
> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
> setup_sched_clock() API") from the tip tree.  The usage was only added
> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
> source for Versatile Express") (but this commit has been in linux-next
> since May 22 at least).
> 
> I have reverted the tip tree commit for today.

Dammit. Why the heck can ARM folks not route their stuff through the
relevant maintainers? Because ARM is a different universe with
different rules or what?

Of course this crap is already in Linus next branch, so it essentially
blocks me from sending my pending timers/core branch.

Patch below. Linus, can you please apply this?

I've ranted about this before. It's not the first time that ARM breaks
stuff I maintain.

Again: Send your stuff against drivers/clocksource and drivers/irqchip
to the maintainers. 

I'm happy to provide you a separate branch to pull that stuff from me,
if you have dependencies on that, but I really don't want to see any
of this again, ever.

Yours seriously grumpy

      tglx

------------>
Subject: clocksource: versatile: Use sched_clock_register()
From: Thomas Gleixner <tglx@linutronix.de>
Date: Wed, 04 Jun 2014 12:34:15 +0200

The newly merged versatile sched clock support uses a deprecated
interface. Of course that patch got routed through the ARM tree
instead of going through the relevant maintainer tree.

Use the proper interface so we can get rid of the cruft.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
index e4c50ad..2798e74 100644
--- a/drivers/clocksource/versatile.c
+++ b/drivers/clocksource/versatile.c
@@ -20,7 +20,7 @@
 
 static void __iomem *versatile_sys_24mhz;
 
-static u32 notrace versatile_sys_24mhz_read(void)
+static u64 notrace versatile_sys_24mhz_read(void)
 {
 	return readl(versatile_sys_24mhz);
 }
@@ -34,7 +34,7 @@ static void __init versatile_sched_clock_init(struct device_node *node)
 
 	versatile_sys_24mhz = base + SYS_24MHZ;
 
-	setup_sched_clock(versatile_sys_24mhz_read, 32, 24000000);
+	sched_clock_register(versatile_sys_24mhz_read, 32, 24000000);
 }
 CLOCKSOURCE_OF_DECLARE(versatile, "arm,vexpress-sysreg",
-		versatile_sched_clock_init);
+		       versatile_sched_clock_init);

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-06-04  6:05 Stephen Rothwell
  2014-06-04 10:49 ` Thomas Gleixner
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-06-04  6:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Pawel Moll, Stephen Boyd, John Stultz

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:


drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]

Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
setup_sched_clock() API") from the tip tree.  The usage was only added
to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
source for Versatile Express") (but this commit has been in linux-next
since May 22 at least).

I have reverted the tip tree commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-05-23  7:14 Stephen Rothwell
@ 2014-05-29  1:38 ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2014-05-29  1:38 UTC (permalink / raw)
  To: Russell King
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

Hi Russell,

On Fri, 23 May 2014 17:14:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from arch/arm/include/asm/outercache.h:24:0,
>                  from arch/arm/include/asm/barrier.h:5,
>                  from arch/arm/include/asm/bitops.h:28,
>                  from include/linux/bitops.h:33,
>                  from include/linux/kernel.h:10,
>                  from include/asm-generic/bug.h:13,
>                  from arch/arm/include/asm/bug.h:61,
>                  from arch/arm/include/asm/div64.h:63,
>                  from include/linux/math64.h:5,
>                  from include/linux/jiffies.h:4,
>                  from init/calibrate.c:7:
> include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
> include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> include/linux/bug.h: In function 'is_warning_bug':
> include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
> 
>  ... and many, many more ...
> 
> Probably caused by commit 030d0178bdbd ("arch,arm: Convert
> smp_mb__*()") which added an include of asm/barrier.h to
> arch/arm/include/asm/bitops.h.  This has interacted with commit
> 59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()")
> from the arm tree, which adds an include of linux/bug.h to
> arch/arm/include/asm/outercache.h.
> 
> I added the below merge fix patch.  Russell, this should be applied to
> your tree directly.

Ping?  I am still carrying this patch ...

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 23 May 2014 17:10:12 +1000
> Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h
> 
> This fixes a cricular include dependency when combined with commits from
> the tip tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm/include/asm/outercache.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
> index eaa8a28c6871..891a56b35bcf 100644
> --- a/arch/arm/include/asm/outercache.h
> +++ b/arch/arm/include/asm/outercache.h
> @@ -21,7 +21,6 @@
>  #ifndef __ASM_OUTERCACHE_H
>  #define __ASM_OUTERCACHE_H
>  
> -#include <linux/bug.h>
>  #include <linux/types.h>
>  
>  struct outer_cache_fns {
> -- 
> 2.0.0.rc4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-05-23  7:14 Stephen Rothwell
  2014-05-29  1:38 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-05-23  7:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Russell King
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/include/asm/outercache.h:24:0,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/kernel.h:10,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from arch/arm/include/asm/div64.h:63,
                 from include/linux/math64.h:5,
                 from include/linux/jiffies.h:4,
                 from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type

 ... and many, many more ...

Probably caused by commit 030d0178bdbd ("arch,arm: Convert
smp_mb__*()") which added an include of asm/barrier.h to
arch/arm/include/asm/bitops.h.  This has interacted with commit
59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()")
from the arm tree, which adds an include of linux/bug.h to
arch/arm/include/asm/outercache.h.

I added the below merge fix patch.  Russell, this should be applied to
your tree directly.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 May 2014 17:10:12 +1000
Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h

This fixes a cricular include dependency when combined with commits from
the tip tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/outercache.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
 #ifndef __ASM_OUTERCACHE_H
 #define __ASM_OUTERCACHE_H
 
-#include <linux/bug.h>
 #include <linux/types.h>
 
 struct outer_cache_fns {
-- 
2.0.0.rc4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-04-24  3:51 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2014-04-24  3:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Russell King

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/include/asm/outercache.h:24:0,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/kernel.h:10,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from arch/arm/include/asm/div64.h:63,
                 from include/linux/math64.h:5,
                 from include/linux/jiffies.h:4,
                 from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
In file included from include/linux/kernel.h:11:0,
                 from include/asm-generic/bug.h:13,
                 from arch/arm/include/asm/bug.h:61,
                 from include/linux/bug.h:4,
                 from arch/arm/include/asm/outercache.h:24,
                 from arch/arm/include/asm/barrier.h:5,
                 from arch/arm/include/asm/bitops.h:28,
                 from include/linux/bitops.h:33,
                 from include/linux/signal.h:35,
                 from arch/arm/kernel/signal.c:12:
include/linux/log2.h: In function '__ilog2_u32':
include/linux/log2.h:34:2: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__ilog2_u64':
include/linux/log2.h:42:2: error: implicit declaration of function 'fls64' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__roundup_pow_of_two':
include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long' [-Werror=implicit-function-declaration]
In file included from include/linux/bitops.h:33:0,
                 from include/linux/signal.h:35,
                 from arch/arm/kernel/signal.c:12:
arch/arm/include/asm/bitops.h: At top level:
arch/arm/include/asm/bitops.h:273:19: error: static declaration of 'fls' follows non-static declaration
include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here

And many more ...

Guessing ... caused by commit febdbfe8a91c ("arch: Prepare for smp_mb__
{before,after}_atomic()") and following interacting with commit
735e532e0f25 ("ARM: outer cache: add WARN_ON() to outer_disable()") from
the arm tree?

I applied this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Apr 2014 13:46:08 +1000
Subject: [PATCH] ARM: outer cache: remove include of linux/bug.h from outercache.h

It causes a circular inclusion and looks like it is not necessary anyway.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/outercache.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
 #ifndef __ASM_OUTERCACHE_H
 #define __ASM_OUTERCACHE_H
 
-#include <linux/bug.h>
 #include <linux/types.h>
 
 struct outer_cache_fns {
-- 
2.0.0.rc0

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-02-12  2:41 Stephen Rothwell
@ 2014-02-12  4:48 ` Preeti U Murthy
  0 siblings, 0 replies; 357+ messages in thread
From: Preeti U Murthy @ 2014-02-12  4:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Nicolas Pitre

Hi Stephen,

On 02/12/2014 08:11 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
> drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration]
>   ppc64_runlatch_off();
>   ^
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog':
> drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration]
>   ppc64_runlatch_on();
>   ^
> 
> Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant
> cpuidle_idle_call()").

Ok so after the commit

d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()
reintroduced ppc64_runlatch_off/on() in drivers/cpuidle/cpuidle-pseries.c
the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines"
now needs to be introduced in part.

Below is the patch which should fix this. This is based on top of tip-tree.

Thanks

Regards
Preeti U Murthy

---------------------------------------------------------------------------------

cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend driver

From: Preeti U Murthy <preeti@linux.vnet.ibm.com>

Commit "d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()"
reintroduced ppc64_runlatch_off/on() in the pseries cpuidle backend driver.
Hence the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines"  in
conjuction with the commit d8c6ad3184ca651 causes a build failure.

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
 drivers/cpuidle/cpuidle-pseries.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index d486489..6f7b019 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -17,6 +17,7 @@
 #include <asm/reg.h>
 #include <asm/machdep.h>
 #include <asm/firmware.h>
+#include <asm/runlatch.h>
 #include <asm/plpar_wrappers.h>
 
 struct cpuidle_driver pseries_idle_driver = {


> 
> I have used the tip tree from next-20140210 again today (since
> next-20140211 was broken differently).
> 

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-02-12  2:41 Stephen Rothwell
  2014-02-12  4:48 ` Preeti U Murthy
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-02-12  2:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Nicolas Pitre, Preeti U Murthy

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration]
  ppc64_runlatch_off();
  ^
drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog':
drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration]
  ppc64_runlatch_on();
  ^

Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant
cpuidle_idle_call()").

I have used the tip tree from next-20140210 again today (since
next-20140211 was broken differently).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-02-11  3:00 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2014-02-11  3:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dongsheng Yang

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: "MAX_USER_PRIO" redefined [-Werror]
 #define MAX_USER_PRIO  (MAX_PRIO - MAX_RT_PRIO)
 ^
In file included from include/linux/sched.h:6:0,
                 from arch/powerpc/platforms/cell/spufs/sched.c:26:
include/linux/sched/prio.h:38:0: note: this is the location of the previous definition
 #define MAX_USER_PRIO  (USER_PRIO(MAX_PRIO))
 ^

Caused by commit 6b6350f155af ("sched: Expose some macros related to
priority").  A quick grep shows that MAX_USER_PRIO is defined in
include/linux/sched/prio.h, but not used anywhere (except in
arch/powerpc/platforms/cell/spufs/sched.c where it is also defined)?

I have used the tip tree from next-20140210 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:51                   ` Peter Zijlstra
  2014-01-21  3:26                     ` Mike Galbraith
@ 2014-01-21 10:47                     ` Ingo Molnar
  1 sibling, 0 replies; 357+ messages in thread
From: Ingo Molnar @ 2014-01-21 10:47 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, H. Peter Anvin, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > > As a side note, at minimum the semantic and compatibility difference
> > > needs to be _very_ clearly present in the naming. Something like
> > > mwait_old_() or mwait_core2_(). That way such dependencies and
> > > assumptions don't get lost in code restructuring, etc.
> > 
> > Agreed.
> > We started with mwait_idle() -- which was erroneously removed
> > and is now being restored under it original name.
> > 
> > The "new" function is mwait_idle_with_hints() -- which uses the 
> > additional hints that were not available w/ the original MWAIT 
> > instruction. Where "new" is Core Duo and later -- all the 
> > processor that can use MWAIT for C-states deeper than C1.
> 
> I'm still waiting for someone to explain what's wrong with:
> 
> static inline void mwait_idle(void)
> {
> 	local_irq_enable();
> 	mwait_idle_with_hints(0, 0);
> }

Absolutely agreed, we don't want to carry it on 'just because', the 
compatibility aspect needs to be documented - otherwise we degrade 
into cargo cult programming.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:51                   ` Peter Zijlstra
@ 2014-01-21  3:26                     ` Mike Galbraith
  2014-01-21 10:47                     ` Ingo Molnar
  1 sibling, 0 replies; 357+ messages in thread
From: Mike Galbraith @ 2014-01-21  3:26 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Ingo Molnar, H. Peter Anvin, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On Mon, 2014-01-20 at 22:51 +0100, Peter Zijlstra wrote:

> I'm still waiting for someone to explain what's wrong with:
> 
> static inline void mwait_idle(void)
> {
> 	local_irq_enable();
> 	mwait_idle_with_hints(0, 0);
> }

How about just do that going forward, it work, and can always be fixed
if something turns up, and the below for stable once it hits mainline?

Q6600 box is happy camper in all trees.

From: Len Brown <len.brown@intel.com>

x86 idle: restore mwait_idle()

In Linux-3.9 we removed the mwait_idle() loop:
'x86 idle: remove mwait_idle() and "idle=mwait" cmdline param'
(69fb3676df3329a7142803bb3502fa59dc0db2e3)

The reasoning was that modern machines should be sufficiently
happy during the boot process using the default_idle() HALT loop,
until cpuidle loads and either acpi_idle or intel_idle
invoke the newer MWAIT-with-hints idle loop.

But two machines reported problems:
1. Certain Core2-era machines support MWAIT-C1 and HALT only.
   MWAIT-C1 is preferred for optimal power and performance.
   But if they support just C1, cpuidle never loads and
   so they use the boot-time default idle loop forever.

2. Some laptops will boot-hang if HALT is used,
   but will boot successfully if MWAIT is used.
   This appears to be a hidden assumption in BIOS SMI,
   that is presumably valid on the proprietary OS
   where the BIOS was validated.

   https://bugzilla.kernel.org/show_bug.cgi?id=60770

So here we effectively revert the patch above, restoring
the mwait_idle() loop.  However, we don't bother restoring
the idle=mwait cmdline parameter, since it appears to add
no value.

Maintainer notes:
For 3.9, simply revert 69fb3676df
for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context
For 3.11, 3.12, 3.13, this patch applies cleanly

Mike: reinstate polling, and add clflush barriers.

Cc: Mike Galbraith <bitbucket@online.de>
Cc: Ian Malone <ibmalone@gmail.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org> # 3.9, 3.10, 3.11, 3.12, 3.13
Signed-off-by: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Len Brown <len.brown@intel.com>
---
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8b5..c5db2a43e730 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -398,6 +398,52 @@ static void amd_e400_idle(void)
 		default_idle();
 }
 
+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+	if (c->x86_vendor != X86_VENDOR_INTEL)
+		return 0;
+
+	if (!cpu_has(c, X86_FEATURE_MWAIT))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+
+static void mwait_idle(void)
+{
+	if (!current_set_polling_and_test()) {
+		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+			mb();
+			clflush((void *)&current_thread_info()->flags);
+			mb();
+		}
+
+		__monitor((void *)&current_thread_info()->flags, 0, 0);
+		if (!need_resched())
+			__sti_mwait(0, 0);
+		else
+			local_irq_enable();
+	} else
+		local_irq_enable();
+	__current_clr_polling();
+}
+
 void select_idle_routine(const struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
@@ -411,6 +457,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c)
 		/* E400: APIC timer interrupt does not wake up CPU from C1e */
 		pr_info("using AMD E400 aware idle routine\n");
 		x86_idle = amd_e400_idle;
+	} else if (prefer_mwait_c1_over_halt(c)) {
+		pr_info("using mwait in idle threads\n");
+		x86_idle = mwait_idle;
 	} else
 		x86_idle = default_idle;
 }
 

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 21:39                 ` Len Brown
@ 2014-01-20 21:51                   ` Peter Zijlstra
  2014-01-21  3:26                     ` Mike Galbraith
  2014-01-21 10:47                     ` Ingo Molnar
  0 siblings, 2 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20 21:51 UTC (permalink / raw)
  To: Len Brown
  Cc: Ingo Molnar, H. Peter Anvin, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel

On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > As a side note, at minimum the semantic and compatibility difference
> > needs to be _very_ clearly present in the naming. Something like
> > mwait_old_() or mwait_core2_(). That way such dependencies and
> > assumptions don't get lost in code restructuring, etc.
> 
> Agreed.
> We started with mwait_idle() -- which was erroneously removed
> and is now being restored under it original name.
> 
> The "new" function is mwait_idle_with_hints() -- which uses
> the additional hints that were not available w/ the original MWAIT instruction.
> Where "new" is Core Duo and later -- all the processor that can use
> MWAIT for C-states deeper than C1.

I'm still waiting for someone to explain what's wrong with:

static inline void mwait_idle(void)
{
	local_irq_enable();
	mwait_idle_with_hints(0, 0);
}

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:29               ` Ingo Molnar
@ 2014-01-20 21:39                 ` Len Brown
  2014-01-20 21:51                   ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: Len Brown @ 2014-01-20 21:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: H. Peter Anvin, Peter Zijlstra, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

> As a side note, at minimum the semantic and compatibility difference
> needs to be _very_ clearly present in the naming. Something like
> mwait_old_() or mwait_core2_(). That way such dependencies and
> assumptions don't get lost in code restructuring, etc.

Agreed.
We started with mwait_idle() -- which was erroneously removed
and is now being restored under it original name.

The "new" function is mwait_idle_with_hints() -- which uses
the additional hints that were not available w/ the original MWAIT instruction.
Where "new" is Core Duo and later -- all the processor that can use
MWAIT for C-states deeper than C1.

Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 13:10                     ` Stephen Rothwell
@ 2014-01-20 15:28                       ` Sedat Dilek
  0 siblings, 0 replies; 357+ messages in thread
From: Sedat Dilek @ 2014-01-20 15:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 2:10 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Sedat,
>
> On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>
>> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>> >>>
>> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> >>> Q6600 box.  See below for an alternative.
>> >>>
>> >>> idle: kill unnecessary mwait_idle() resched IPIs
>> >>
>> >> OK, so despite even further discussion, I have applied this as a merge
>> >> fix patch for today.  Let me know when it is all sorted out.
>> >>
>> >
>> > Where is this fix?
>> > ( Browsing Linux-next remote GIT repository online. )
>> > 2x NOPE for me.
>> >
>> > - Sedat -
>> >
>> > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
>> > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
>> >
>>
>> Hmmm... Found this in Next/merge.log
>>
>> +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
>> +Applying: idle: kill unnecessary mwait_idle() resched IPIs
>> +$ git reset HEAD^
>> +Unstaged changes after reset:
>> +M arch/x86/include/asm/processor.h
>> +M arch/x86/kernel/process.c
>
> You missed the next three lines:
>
> $ git add -A .
> $ git commit -v -a --amend
> [master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest'
>

[ I was absent for a while from Linux-next, so I am asking for clarification. ]
[ I might be wrong. ]

What does that mean?
AFAICS you applied an important fix by yourself on top of tip/auto-latest?

>> Is this a local patch not shipped in the Linux-next (remote) GIT repo?
>> Why is this not in your next-fixes GIT repo?
>
> Its part of the conflict resolution for the merge of the tip tree.  It
> cannot go into my fixes tree - that is for fixes to bugs in Linus' tree
> until they are integrated there.  The tip and pm trees are both fine on
> their own, but combined they don't.  So this fix has to go into the actual
> merge commit for the merge of the later tree.   When Linus' merges the
> later of these trees he will also need this fix - or a better one - which
> is what is still under discussion.
>

I was asking in general about next-fixes to have a "bootable" (aka
working) Linux-next kernel.

You see next-fixes as a place to fix Linus-tree, seriously?

The question here in this special case seems to be a "logical"
(not-working-together) problem between tip and pm.

And we are in a merge-window...

>> A bit confused about your -next policies,
>
> Any better?
>

Not really.
You should clarify on what you are doing in your next-fixes tree.
Your daily report for Linux-next releases even does not mention next-fixes.

Looking through my INBOX Thierry had the initial idea of "fixes for
linux-next" when you were on vacation and he took over maintainership.

- Sedat -

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:46                   ` Sedat Dilek
@ 2014-01-20 13:10                     ` Stephen Rothwell
  2014-01-20 15:28                       ` Sedat Dilek
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-20 13:10 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi Sedat,

On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
> >>>
> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> >>> Q6600 box.  See below for an alternative.
> >>>
> >>> idle: kill unnecessary mwait_idle() resched IPIs
> >>
> >> OK, so despite even further discussion, I have applied this as a merge
> >> fix patch for today.  Let me know when it is all sorted out.
> >>
> >
> > Where is this fix?
> > ( Browsing Linux-next remote GIT repository online. )
> > 2x NOPE for me.
> >
> > - Sedat -
> >
> > [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
> > [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
> >
> 
> Hmmm... Found this in Next/merge.log
> 
> +$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
> +Applying: idle: kill unnecessary mwait_idle() resched IPIs
> +$ git reset HEAD^
> +Unstaged changes after reset:
> +M arch/x86/include/asm/processor.h
> +M arch/x86/kernel/process.c

You missed the next three lines:

$ git add -A .
$ git commit -v -a --amend
[master 65d9a14a9a41] Merge remote-tracking branch 'tip/auto-latest'

> Is this a local patch not shipped in the Linux-next (remote) GIT repo?
> Why is this not in your next-fixes GIT repo?

Its part of the conflict resolution for the merge of the tip tree.  It
cannot go into my fixes tree - that is for fixes to bugs in Linus' tree
until they are integrated there.  The tip and pm trees are both fine on
their own, but combined they don't.  So this fix has to go into the actual
merge commit for the merge of the later tree.   When Linus' merges the
later of these trees he will also need this fix - or a better one - which
is what is still under discussion.

> A bit confused about your -next policies,

Any better?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 10:19       ` H. Peter Anvin
@ 2014-01-20 11:06         ` Peter Zijlstra
  0 siblings, 0 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20 11:06 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 02:19:30AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> > On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> >> Then make them so. The fact was that most of the mwait idle sites
> >> were bloody broken. And the single mwait_idle_with_hints() function
> >> presents a single nice function that does all the required magics.
> > 
> > To stress this a bit more; have a look see at mwwait_idle_with_hints();
> > it does a whole lot of subtle magic.
> > 
> >  - current_{set,clr}_polling*(), these are crucial in not missing and
> >    wrecking NEED_RESCHED state.
> > 
> >  - X86_FEATURE_CLFLUSH_MONTIOR quirk
> > 
> >  - Does the monitor(); if (!need_resched()) mwait() thing.
> > 
> > All of those are required for a correct and functional idle loop. And
> > I've seen sites where any or all of the above were missing/broken.
> > 
> > Not unifying the lot into a simple usable function is just stupid --
> > history has shown people simply cannot be trusted to get this right.
> > 
> 
> I don't think anyone is arguing that.  The question is rather if the
> implementation is correct, and if it is ready for the merge window.

I've yet to hear an argument against it other than vaguaries.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 11:00                 ` H. Peter Anvin
@ 2014-01-20 11:05                   ` Peter Zijlstra
  0 siblings, 0 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20 11:05 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 03:00:29AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> > 
> > Ok, so I still don't get the problem of enabling interrupts early.
> > 
> > If we enable them early we can get interrupts; which afaict fall into
> > two groups, those that do and do not set NEED_RESCHED.
> > 
> > For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> > and looped right back into it, so receiving those early -- before
> > actually calling MWAIT/HLT seems like a NO-OP.
> 
> The description for commit d331e739f5ad seems to indicate otherwise:
> 
>     Idle callbacks has some races when enter_idle() sets isidle and
> subsequent
>     interrupts that can happen on that CPU, before CPU goes to idle. Due
> to this,
>     an IDLE_END can get called before IDLE_START. To avoid these races,
> disable
>     interrupts before enter_idle and make sure that all idle routines do not
>     enable interrupts before entering idle.
> 
> This implies to me that once we have set isidle, if we take an interrupt
> we *have* to drop out of the idle routine.

I don't think that applies anymore; the generic idle loop calls
arch_cpu_idle_enter() before calling arch_cpu_idle() where we would do
the enable.

So in that sense its impossible to get arch_cpu_idle_exit() -- or rather
exit_idle() as called from the interrupts -- to happen before
arch_cpu_idle_enter().

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:55               ` Peter Zijlstra
@ 2014-01-20 11:00                 ` H. Peter Anvin
  2014-01-20 11:05                   ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-20 11:00 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> 
> Ok, so I still don't get the problem of enabling interrupts early.
> 
> If we enable them early we can get interrupts; which afaict fall into
> two groups, those that do and do not set NEED_RESCHED.
> 
> For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
> and looped right back into it, so receiving those early -- before
> actually calling MWAIT/HLT seems like a NO-OP.

The description for commit d331e739f5ad seems to indicate otherwise:

    Idle callbacks has some races when enter_idle() sets isidle and
subsequent
    interrupts that can happen on that CPU, before CPU goes to idle. Due
to this,
    an IDLE_END can get called before IDLE_START. To avoid these races,
disable
    interrupts before enter_idle and make sure that all idle routines do not
    enable interrupts before entering idle.

This implies to me that once we have set isidle, if we take an interrupt
we *have* to drop out of the idle routine.

> For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
> places.
> 
>  - current_set_polling_and_test(), we test need_resched after telling
>    remote CPUs they don't need to send interrupts because we're polling
>    for it -- the remote cpus set NEED_RESCHED before testing if we're
>    polling for it.
> 
>  - we test NEED_RESCHED after setting up the monitor and before calling
>    MWAIT. Therefore, if an interrupt would happen right before we call
>    MWAIT, the monitor is already set and the MWAIT does an immediate
>    exit.
> 
> AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.
> 

Well, it is obviously needed for the HLT case.  For MWAIT it seems like
the MONITOR should have gotten disarmed and therefore MWAIT shouldn't
sleep... I don't know off the top of my head if there are any errata in
that department and/or if there are any other issues.

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20 10:13     ` Peter Zijlstra
@ 2014-01-20 10:19       ` H. Peter Anvin
  2014-01-20 11:06         ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-20 10:19 UTC (permalink / raw)
  To: Peter Zijlstra, Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
>> Then make them so. The fact was that most of the mwait idle sites
>> were bloody broken. And the single mwait_idle_with_hints() function
>> presents a single nice function that does all the required magics.
> 
> To stress this a bit more; have a look see at mwwait_idle_with_hints();
> it does a whole lot of subtle magic.
> 
>  - current_{set,clr}_polling*(), these are crucial in not missing and
>    wrecking NEED_RESCHED state.
> 
>  - X86_FEATURE_CLFLUSH_MONTIOR quirk
> 
>  - Does the monitor(); if (!need_resched()) mwait() thing.
> 
> All of those are required for a correct and functional idle loop. And
> I've seen sites where any or all of the above were missing/broken.
> 
> Not unifying the lot into a simple usable function is just stupid --
> history has shown people simply cannot be trusted to get this right.
> 

I don't think anyone is arguing that.  The question is rather if the
implementation is correct, and if it is ready for the merge window.

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:30   ` Peter Zijlstra
@ 2014-01-20 10:13     ` Peter Zijlstra
  2014-01-20 10:19       ` H. Peter Anvin
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20 10:13 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> Then make them so. The fact was that most of the mwait idle sites
> were bloody broken. And the single mwait_idle_with_hints() function
> presents a single nice function that does all the required magics.

To stress this a bit more; have a look see at mwwait_idle_with_hints();
it does a whole lot of subtle magic.

 - current_{set,clr}_polling*(), these are crucial in not missing and
   wrecking NEED_RESCHED state.

 - X86_FEATURE_CLFLUSH_MONTIOR quirk

 - Does the monitor(); if (!need_resched()) mwait() thing.

All of those are required for a correct and functional idle loop. And
I've seen sites where any or all of the above were missing/broken.

Not unifying the lot into a simple usable function is just stupid --
history has shown people simply cannot be trusted to get this right.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:23             ` H. Peter Anvin
  2014-01-20  9:29               ` Ingo Molnar
@ 2014-01-20  9:55               ` Peter Zijlstra
  2014-01-20 11:00                 ` H. Peter Anvin
  1 sibling, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20  9:55 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> > 
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> > 
> 
> No, that doesn't work.  The point of __sti_mwait() is that the STI is
> the instruction immediately before the MWAIT, just like the combination
> STI;HLT.  Since the execution of STI is always delayed by one
> instruction, these two instructions form an atomic unit, which means
> interrupts are enabled "after" we have entered MWAIT or HLT.
> 
> > But that's entirely different from saying that core2 doesn't support
> > mwait_idle_with_hints because its a different instruction.
> 
> If you think of STI;MWAIT as a "compound instruction" it kind of is.
> Newer CPUs don't have to play that trick anymore, because there is a
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt
> without having to actually enable interrupts at the point of the MWAIT.

Ok, so I still don't get the problem of enabling interrupts early.

If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not set NEED_RESCHED.

For those that do not set NEED_RESCHED, we'd have woken from MWAIT/HLT
and looped right back into it, so receiving those early -- before
actually calling MWAIT/HLT seems like a NO-OP.

For those setting NEED_RESCHED, we test NEED_RESCHED in all the right
places.

 - current_set_polling_and_test(), we test need_resched after telling
   remote CPUs they don't need to send interrupts because we're polling
   for it -- the remote cpus set NEED_RESCHED before testing if we're
   polling for it.

 - we test NEED_RESCHED after setting up the monitor and before calling
   MWAIT. Therefore, if an interrupt would happen right before we call
   MWAIT, the monitor is already set and the MWAIT does an immediate
   exit.

AFAICT we simply cannot get stuck and miss a NEED_RESCHED this way.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:25                     ` Sedat Dilek
@ 2014-01-20  9:48                       ` Mike Galbraith
  0 siblings, 0 replies; 357+ messages in thread
From: Mike Galbraith @ 2014-01-20  9:48 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, 2014-01-20 at 10:25 +0100, Sedat Dilek wrote:

> It's about the handling of fixes for -next.

Ah, it was a gripe in query form.  My bad.

-Mike

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:23             ` H. Peter Anvin
@ 2014-01-20  9:29               ` Ingo Molnar
  2014-01-20 21:39                 ` Len Brown
  2014-01-20  9:55               ` Peter Zijlstra
  1 sibling, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2014-01-20  9:29 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Peter Zijlstra, Len Brown, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, linux-next, linux-kernel


* H. Peter Anvin <hpa@zytor.com> wrote:

> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> > 
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> > 
> 
> No, that doesn't work.  The point of __sti_mwait() is that the STI 
> is the instruction immediately before the MWAIT, just like the 
> combination STI;HLT.  Since the execution of STI is always delayed 
> by one instruction, these two instructions form an atomic unit, 
> which means interrupts are enabled "after" we have entered MWAIT or 
> HLT.
> 
> > But that's entirely different from saying that core2 doesn't 
> > support mwait_idle_with_hints because its a different instruction.
> 
> If you think of STI;MWAIT as a "compound instruction" it kind of is. 
> Newer CPUs don't have to play that trick anymore, because there is a 
> flag to MWAIT which breaks us out of MWAIT on a pending interrupt 
> without having to actually enable interrupts at the point of the 
> MWAIT.

As a side note, at minimum the semantic and compatibility difference 
needs to be _very_ clearly present in the naming. Something like 
mwait_old_() or mwait_core2_(). That way such dependencies and 
assumptions don't get lost in code restructuring, etc.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:17                   ` Mike Galbraith
@ 2014-01-20  9:25                     ` Sedat Dilek
  2014-01-20  9:48                       ` Mike Galbraith
  0 siblings, 1 reply; 357+ messages in thread
From: Sedat Dilek @ 2014-01-20  9:25 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 10:17 AM, Mike Galbraith <bitbucket@online.de> wrote:
> On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
>> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>> >>
>> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> >> Q6600 box.  See below for an alternative.
>> >>
>> >> idle: kill unnecessary mwait_idle() resched IPIs
>> >
>> > OK, so despite even further discussion, I have applied this as a merge
>> > fix patch for today.  Let me know when it is all sorted out.
>> >
>>
>> Where is this fix?
>
> If you pull next-20140120, the fix is in it.
>
>> ( Browsing Linux-next remote GIT repository online. )
>> 2x NOPE for me.
>
> Probably because it's a temporary conflict fix.
>

It's about the handling of fixes for -next.
For such kind of "special" tweaks Stephen introduced *next-fixes* (see
his email on linux-next ML and [1]).
Such make-my-system-boot-again and other critical fixes belong there.

BTW, I found the merge hunk (see my other email).

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  9:16           ` Peter Zijlstra
@ 2014-01-20  9:23             ` H. Peter Anvin
  2014-01-20  9:29               ` Ingo Molnar
  2014-01-20  9:55               ` Peter Zijlstra
  0 siblings, 2 replies; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-20  9:23 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
>>
>> The difference is the STI!
> 
> So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> 

No, that doesn't work.  The point of __sti_mwait() is that the STI is
the instruction immediately before the MWAIT, just like the combination
STI;HLT.  Since the execution of STI is always delayed by one
instruction, these two instructions form an atomic unit, which means
interrupts are enabled "after" we have entered MWAIT or HLT.

> But that's entirely different from saying that core2 doesn't support
> mwait_idle_with_hints because its a different instruction.

If you think of STI;MWAIT as a "compound instruction" it kind of is.
Newer CPUs don't have to play that trick anymore, because there is a
flag to MWAIT which breaks us out of MWAIT on a pending interrupt
without having to actually enable interrupts at the point of the MWAIT.

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:42                 ` Sedat Dilek
  2014-01-20  8:46                   ` Sedat Dilek
@ 2014-01-20  9:17                   ` Mike Galbraith
  2014-01-20  9:25                     ` Sedat Dilek
  1 sibling, 1 reply; 357+ messages in thread
From: Mike Galbraith @ 2014-01-20  9:17 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Stephen Rothwell, H. Peter Anvin, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, LKML

On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote: 
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
> >>
> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> >> Q6600 box.  See below for an alternative.
> >>
> >> idle: kill unnecessary mwait_idle() resched IPIs
> >
> > OK, so despite even further discussion, I have applied this as a merge
> > fix patch for today.  Let me know when it is all sorted out.
> >
> 
> Where is this fix?

If you pull next-20140120, the fix is in it.

> ( Browsing Linux-next remote GIT repository online. )
> 2x NOPE for me.

Probably because it's a temporary conflict fix.

-Mike

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:56         ` H. Peter Anvin
@ 2014-01-20  9:16           ` Peter Zijlstra
  2014-01-20  9:23             ` H. Peter Anvin
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20  9:16 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	linux-next, linux-kernel

On Mon, Jan 20, 2014 at 12:56:47AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> > On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> >> +static void mwait_idle(void)
> >> +{
> >> +       mwait_idle_with_hints(0, 0);
> >> +}
> >> +
> >>
> >> The reason the patch above will crash Core2 machines is because
> >> core2 machines don't support mwait_idle_with_hints().
> >>
> >> The calling sequence for old and new MWAIT instructions is different.
> >> The former must be invoked with interrupts enabled,
> >> and the later can be invoked with interrupts disabled,
> >> which is a feature that Linux takes advantage of.
> > 
> > What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
> > 
> > And your 'old' __sti_mwait(0,0) has the exact same arguments as
> > mwait_idle_with_hints(0,0).
> > 
> 
> The difference is the STI!

So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.

But that's entirely different from saying that core2 doesn't support
mwait_idle_with_hints because its a different instruction.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:26       ` Peter Zijlstra
@ 2014-01-20  8:56         ` H. Peter Anvin
  2014-01-20  9:16           ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-20  8:56 UTC (permalink / raw)
  To: Peter Zijlstra, Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, linux-next, linux-kernel

On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
>> +static void mwait_idle(void)
>> +{
>> +       mwait_idle_with_hints(0, 0);
>> +}
>> +
>>
>> The reason the patch above will crash Core2 machines is because
>> core2 machines don't support mwait_idle_with_hints().
>>
>> The calling sequence for old and new MWAIT instructions is different.
>> The former must be invoked with interrupts enabled,
>> and the later can be invoked with interrupts disabled,
>> which is a feature that Linux takes advantage of.
> 
> What old and new? They're the same byte sequence: 0x0f 0x01 0xc9
> 
> And your 'old' __sti_mwait(0,0) has the exact same arguments as
> mwait_idle_with_hints(0,0).
> 

The difference is the STI!

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  8:42                 ` Sedat Dilek
@ 2014-01-20  8:46                   ` Sedat Dilek
  2014-01-20 13:10                     ` Stephen Rothwell
  2014-01-20  9:17                   ` Mike Galbraith
  1 sibling, 1 reply; 357+ messages in thread
From: Sedat Dilek @ 2014-01-20  8:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box.  See below for an alternative.
>>>
>>> idle: kill unnecessary mwait_idle() resched IPIs
>>
>> OK, so despite even further discussion, I have applied this as a merge
>> fix patch for today.  Let me know when it is all sorted out.
>>
>
> Where is this fix?
> ( Browsing Linux-next remote GIT repository online. )
> 2x NOPE for me.
>
> - Sedat -
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
> [2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git
>

Hmmm... Found this in Next/merge.log

+$ git am -3 ../patches/0001-x86-idle-mwait_idle-merge-update.patch
+Applying: idle: kill unnecessary mwait_idle() resched IPIs
+$ git reset HEAD^
+Unstaged changes after reset:
+M arch/x86/include/asm/processor.h
+M arch/x86/kernel/process.c

Is this a local patch not shipped in the Linux-next (remote) GIT repo?
Why is this not in your next-fixes GIT repo?

A bit confused about your -next policies,
- Sedat -

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  3:51               ` Stephen Rothwell
@ 2014-01-20  8:42                 ` Sedat Dilek
  2014-01-20  8:46                   ` Sedat Dilek
  2014-01-20  9:17                   ` Mike Galbraith
  0 siblings, 2 replies; 357+ messages in thread
From: Sedat Dilek @ 2014-01-20  8:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Galbraith, H. Peter Anvin, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Len Brown, linux-next, LKML

On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>>
>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> Q6600 box.  See below for an alternative.
>>
>> idle: kill unnecessary mwait_idle() resched IPIs
>
> OK, so despite even further discussion, I have applied this as a merge
> fix patch for today.  Let me know when it is all sorted out.
>

Where is this fix?
( Browsing Linux-next remote GIT repository online. )
2x NOPE for me.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20140120&qt=grep&q=mwait_idle
[2] http://git.kernel.org/cgit/linux/kernel/git/sfr/next-fixes.git

> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  1:00 ` Len Brown
  2014-01-20  1:07   ` H. Peter Anvin
@ 2014-01-20  8:30   ` Peter Zijlstra
  2014-01-20 10:13     ` Peter Zijlstra
  1 sibling, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20  8:30 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Sun, Jan 19, 2014 at 08:00:19PM -0500, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > arch/x86/kernel/process.c: In function 'mwait_idle':
> > /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
> >    __monitor((void *)&current_thread_info()->flags, 0, 0);
> >    ^
> > arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
> >     __sti_mwait(0, 0);
> >     ^
> >
> > Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> > idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> > mwait_idle()") from the idle tree.
> >
> > I am not sure how to fix this so I just reverted the idle tree commit for
> > now (since it reverted cleanly). Please let me know if there is a better
> > solution.
> 
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.

It was part of that other regression fix, the 50+ watt thingy for your
broken EX chips.

It was also written much earlier and widely mailed and published before
you did the core2 thing.

> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...

Then make them so. The fact was that most of the mwait idle sites
were bloody broken. And the single mwait_idle_with_hints() function
presents a single nice function that does all the required magics.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  4:45     ` Len Brown
@ 2014-01-20  8:26       ` Peter Zijlstra
  2014-01-20  8:56         ` H. Peter Anvin
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-20  8:26 UTC (permalink / raw)
  To: Len Brown
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> +static void mwait_idle(void)
> +{
> +       mwait_idle_with_hints(0, 0);
> +}
> +
> 
> The reason the patch above will crash Core2 machines is because
> core2 machines don't support mwait_idle_with_hints().
> 
> The calling sequence for old and new MWAIT instructions is different.
> The former must be invoked with interrupts enabled,
> and the later can be invoked with interrupts disabled,
> which is a feature that Linux takes advantage of.

What old and new? They're the same byte sequence: 0x0f 0x01 0xc9

And your 'old' __sti_mwait(0,0) has the exact same arguments as
mwait_idle_with_hints(0,0).

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 22:25     ` Peter Zijlstra
@ 2014-01-20  4:45     ` Len Brown
  2014-01-20  8:26       ` Peter Zijlstra
  1 sibling, 1 reply; 357+ messages in thread
From: Len Brown @ 2014-01-20  4:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel

+static void mwait_idle(void)
+{
+       mwait_idle_with_hints(0, 0);
+}
+

The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().

The calling sequence for old and new MWAIT instructions is different.
The former must be invoked with interrupts enabled,
and the later can be invoked with interrupts disabled,
which is a feature that Linux takes advantage of.

thanks,
-Len

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18  9:46             ` Mike Galbraith
  2014-01-18 12:44               ` Peter Zijlstra
@ 2014-01-20  3:51               ` Stephen Rothwell
  2014-01-20  8:42                 ` Sedat Dilek
  1 sibling, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-20  3:51 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: H. Peter Anvin, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith <bitbucket@online.de> wrote:
>
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box.  See below for an alternative.
> 
> idle: kill unnecessary mwait_idle() resched IPIs

OK, so despite even further discussion, I have applied this as a merge
fix patch for today.  Let me know when it is all sorted out.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-20  1:00 ` Len Brown
@ 2014-01-20  1:07   ` H. Peter Anvin
  2014-01-20  8:30   ` Peter Zijlstra
  1 sibling, 0 replies; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-20  1:07 UTC (permalink / raw)
  To: Len Brown, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel

On 01/19/2014 05:00 PM, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> arch/x86/kernel/process.c: In function 'mwait_idle':
>> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>>    ^
>> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>>     __sti_mwait(0, 0);
>>     ^
>>
>> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
>> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
>> mwait_idle()") from the idle tree.
>>
>> I am not sure how to fix this so I just reverted the idle tree commit for
>> now (since it reverted cleanly). Please let me know if there is a better
>> solution.
> 
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.
> 
> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...
> 

Sounds like a NAK to me, in which case that bit should probably be
deferred and reintroduced after fixing via the idle tree?

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16  3:58 Stephen Rothwell
  2014-01-16 12:19 ` Peter Zijlstra
@ 2014-01-20  1:00 ` Len Brown
  2014-01-20  1:07   ` H. Peter Anvin
  2014-01-20  8:30   ` Peter Zijlstra
  1 sibling, 2 replies; 357+ messages in thread
From: Len Brown @ 2014-01-20  1:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>    ^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>     __sti_mwait(0, 0);
>     ^
>
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
>
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.

IMO, a regression fix (restore mwait_idle()) is more important than a clean up
(restructure mwait routines), and the clean-up should take a back seat;
in -tip, in -next, upstream, and in -stable.

Also, I'm wondering if that clean-up went too far -- as not all users of mwait
are necessarily under the same conditions...

thanks,
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 19:14                   ` H. Peter Anvin
@ 2014-01-18 21:54                     ` Peter Zijlstra
  0 siblings, 0 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-18 21:54 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Mike Galbraith, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote:
> >> Could something like this work?
> >>
> >> 	local_irq_enable();
> >> 	mwait_idle_with_hints(0,0);
> >>

> This means an interrupt window is open and we can take an interrupt
> between checking need_resched and the MWAIT, which couldn't happen with
> __sti_mwait().
> 
> Are we sure that is actually safe?

current_set_polling_and_test() vs resched_task() should be good that
way, but I've got a terrible head-ache today so don't rely on anything
much I say.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 15:21                 ` Mike Galbraith
@ 2014-01-18 19:14                   ` H. Peter Anvin
  2014-01-18 21:54                     ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-18 19:14 UTC (permalink / raw)
  To: Mike Galbraith, Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Len Brown,
	linux-next, linux-kernel

On 01/18/2014 07:21 AM, Mike Galbraith wrote:
> On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: 
>> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box.  See below for an alternative.
>>
>> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
>> disabled.
>>
>> Could something like this work?
>>
>> 	local_irq_enable();
>> 	mwait_idle_with_hints(0,0);
>>
>> The interrupt enable window is slightly larger, but I'm not immediately
>> seeing a problem with that.
> 
> Yup, works just fine.  Less is more.
> 
> Nice to see a _progression_ in the pipe too btw.
> 

This means an interrupt window is open and we can take an interrupt
between checking need_resched and the MWAIT, which couldn't happen with
__sti_mwait().

Are we sure that is actually safe?

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 12:44               ` Peter Zijlstra
  2014-01-18 14:06                 ` Sabrina Dubroca
@ 2014-01-18 15:21                 ` Mike Galbraith
  2014-01-18 19:14                   ` H. Peter Anvin
  1 sibling, 1 reply; 357+ messages in thread
From: Mike Galbraith @ 2014-01-18 15:21 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: 
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> > 
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box.  See below for an alternative.
> 
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
> 
> Could something like this work?
> 
> 	local_irq_enable();
> 	mwait_idle_with_hints(0,0);
> 
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.

Yup, works just fine.  Less is more.

Nice to see a _progression_ in the pipe too btw.

-Mike

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18 12:44               ` Peter Zijlstra
@ 2014-01-18 14:06                 ` Sabrina Dubroca
  2014-01-18 15:21                 ` Mike Galbraith
  1 sibling, 0 replies; 357+ messages in thread
From: Sabrina Dubroca @ 2014-01-18 14:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Mike Galbraith, Stephen Rothwell, H. Peter Anvin,
	Thomas Gleixner, Ingo Molnar, Len Brown, linux-next,
	linux-kernel

2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> > 
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box.  See below for an alternative.
> 
> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
> disabled.
> 
> Could something like this work?
> 
> 	local_irq_enable();
> 	mwait_idle_with_hints(0,0);
> 
> The interrupt enable window is slightly larger, but I'm not immediately
> seeing a problem with that.

next-20140117 doesn't boot on my T7300 laptop either. I've tried the
two fixes, they both work for me.


Thanks,

-- 
Sabrina

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-18  9:46             ` Mike Galbraith
@ 2014-01-18 12:44               ` Peter Zijlstra
  2014-01-18 14:06                 ` Sabrina Dubroca
  2014-01-18 15:21                 ` Mike Galbraith
  2014-01-20  3:51               ` Stephen Rothwell
  1 sibling, 2 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-18 12:44 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Stephen Rothwell, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> 
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box.  See below for an alternative.

Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
disabled.

Could something like this work?

	local_irq_enable();
	mwait_idle_with_hints(0,0);

The interrupt enable window is slightly larger, but I'm not immediately
seeing a problem with that.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-17  3:45           ` Stephen Rothwell
@ 2014-01-18  9:46             ` Mike Galbraith
  2014-01-18 12:44               ` Peter Zijlstra
  2014-01-20  3:51               ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Mike Galbraith @ 2014-01-18  9:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: H. Peter Anvin, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Len Brown, linux-next, linux-kernel

On Fri, 2014-01-17 at 14:45 +1100, Stephen Rothwell wrote: 
> Hi all,
> 
> On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > > 
> > > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > > <peterz@infradead.org> wrote:
> > >> 
> > >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> > >> wrote:
> > >>> 
> > >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> > >>> <peterz@infradead.org> wrote:
> > >>>> 
> > >>>> I think the below ought to work
> > >>> 
> > >>> To be clear, all you did was replace the body of mwait_idle()
> > >>> with
> > >>> 
> > >>> mwait_idle_with_hints(0, 0);
> > >> 
> > >> Pretty much, and add the asm/mwait.h include, otherwise you'll
> > >> end up with a compile fail.
> > >> 
> > >>> (and the comment above it)?  I need to apply in incremental
> > >>> patch in the merge commit.
> > >> 
> > >> I don't think I touched the comment at all.
> > > 
> > 
> > In retrospect this bit probably should have gone through the idle
> > tree.  That was my bad, I need to coordinate with Len better.
> 
> So this is what I added as a merge fix patch.  Someone just needs to make
> sure Linus gets this when the latter of the tow trees gets merged.

I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box.  See below for an alternative.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Jan 2014 14:42:06 +1100
> Subject: [PATCH] x86 idle: mwait_idle merge update
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/process.c | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index db471a87fdd8..4da840f01561 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -28,6 +28,7 @@
>  #include <asm/fpu-internal.h>
>  #include <asm/debugreg.h>
>  #include <asm/nmi.h>
> +#include <asm/mwait.h>
>  
>  /*
>   * per-CPU TSS segments. Threads are completely 'soft' on Linux,
> @@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
>  
>  static void mwait_idle(void)
>  {
> -	if (!need_resched()) {
> -		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
> -			clflush((void *)&current_thread_info()->flags);
> -
> -		__monitor((void *)&current_thread_info()->flags, 0, 0);
> -		smp_mb();
> -		if (!need_resched())
> -			__sti_mwait(0, 0);
> -		else
> -			local_irq_enable();
> -	} else
> -		local_irq_enable();
> +	mwait_idle_with_hints(0, 0);
>  }
>  
>  void select_idle_routine(const struct cpuinfo_x86 *c)
> -- 
> 1.8.5.2

idle: kill unnecessary mwait_idle() resched IPIs

Set/clear polling instead.

Q6600, pipe-test scheduling cross core:
3.8.13                   487.2 KHz    1.000
3.13.0-master            415.5 KHz     .852
3.13.0-master+           415.2 KHz     .852     + restore mwait_idle
3.13.0-master++          488.5 KHz    1.002     + restore mwait_idle + IPI fix
3.13.0-next-20140117     -ENOBOOT
3.13.0-next-20140117+    531.4 KHz    1.090     + IPI fix

Signed-off-by: Mike Galbraith <bitbucket@online.de>
---
 arch/x86/include/asm/processor.h |    8 ++++++++
 arch/x86/kernel/process.c        |   10 +++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -723,6 +723,14 @@ static inline void sync_core(void)
 #endif
 }
 
+static inline void __sti_mwait(unsigned long eax, unsigned long ecx)
+{
+	trace_hardirqs_on();
+	/* "mwait %eax, %ecx;" */
+	asm volatile("sti; .byte 0x0f, 0x01, 0xc9;"
+		     :: "a" (eax), "c" (ecx));
+}
+
 extern void select_idle_routine(const struct cpuinfo_x86 *c);
 extern void init_amd_e400_c1e_mask(void);
 
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -427,18 +428,21 @@ static int prefer_mwait_c1_over_halt(con
 
 static void mwait_idle(void)
 {
-	if (!need_resched()) {
-		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+	if (!current_set_polling_and_test()) {
+		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+			mb();
 			clflush((void *)&current_thread_info()->flags);
+			mb();
+		}
 
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
-		smp_mb();
 		if (!need_resched())
 			__sti_mwait(0, 0);
 		else
 			local_irq_enable();
 	} else
 		local_irq_enable();
+	current_clr_polling();
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:51         ` H. Peter Anvin
@ 2014-01-17  3:45           ` Stephen Rothwell
  2014-01-18  9:46             ` Mike Galbraith
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-17  3:45 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

Hi all,

On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > <peterz@infradead.org> wrote:
> >> 
> >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> >> wrote:
> >>> 
> >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> >>> <peterz@infradead.org> wrote:
> >>>> 
> >>>> I think the below ought to work
> >>> 
> >>> To be clear, all you did was replace the body of mwait_idle()
> >>> with
> >>> 
> >>> mwait_idle_with_hints(0, 0);
> >> 
> >> Pretty much, and add the asm/mwait.h include, otherwise you'll
> >> end up with a compile fail.
> >> 
> >>> (and the comment above it)?  I need to apply in incremental
> >>> patch in the merge commit.
> >> 
> >> I don't think I touched the comment at all.
> > 
> 
> In retrospect this bit probably should have gone through the idle
> tree.  That was my bad, I need to coordinate with Len better.

So this is what I added as a merge fix patch.  Someone just needs to make
sure Linus gets this when the latter of the tow trees gets merged.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Jan 2014 14:42:06 +1100
Subject: [PATCH] x86 idle: mwait_idle merge update

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/process.c | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index db471a87fdd8..4da840f01561 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
 
 static void mwait_idle(void)
 {
-	if (!need_resched()) {
-		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
-			clflush((void *)&current_thread_info()->flags);
-
-		__monitor((void *)&current_thread_info()->flags, 0, 0);
-		smp_mb();
-		if (!need_resched())
-			__sti_mwait(0, 0);
-		else
-			local_irq_enable();
-	} else
-		local_irq_enable();
+	mwait_idle_with_hints(0, 0);
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)
-- 
1.8.5.2


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:34       ` Stephen Rothwell
@ 2014-01-16 22:51         ` H. Peter Anvin
  2014-01-17  3:45           ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-16 22:51 UTC (permalink / raw)
  To: Stephen Rothwell, Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, linux-kernel

On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> <peterz@infradead.org> wrote:
>> 
>> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
>> wrote:
>>> 
>>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
>>> <peterz@infradead.org> wrote:
>>>> 
>>>> I think the below ought to work
>>> 
>>> To be clear, all you did was replace the body of mwait_idle()
>>> with
>>> 
>>> mwait_idle_with_hints(0, 0);
>> 
>> Pretty much, and add the asm/mwait.h include, otherwise you'll
>> end up with a compile fail.
>> 
>>> (and the comment above it)?  I need to apply in incremental
>>> patch in the merge commit.
>> 
>> I don't think I touched the comment at all.
> 

In retrospect this bit probably should have gone through the idle
tree.  That was my bad, I need to coordinate with Len better.

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 22:25     ` Peter Zijlstra
@ 2014-01-16 22:34       ` Stephen Rothwell
  2014-01-16 22:51         ` H. Peter Anvin
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-16 22:34 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Hi Peter,

On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > I think the below ought to work
> > 
> > To be clear, all you did was replace the body of mwait_idle() with
> > 
> > 	mwait_idle_with_hints(0, 0);
> 
> Pretty much, and add the asm/mwait.h include, otherwise you'll end up
> with a compile fail.
> 
> > (and the comment above it)?  I need to apply in incremental patch in the
> > merge commit.
> 
> I don't think I touched the comment at all.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 20:46   ` Stephen Rothwell
@ 2014-01-16 22:25     ` Peter Zijlstra
  2014-01-16 22:34       ` Stephen Rothwell
  2014-01-20  4:45     ` Len Brown
  1 sibling, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-16 22:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > I think the below ought to work
> 
> To be clear, all you did was replace the body of mwait_idle() with
> 
> 	mwait_idle_with_hints(0, 0);

Pretty much, and add the asm/mwait.h include, otherwise you'll end up
with a compile fail.

> (and the comment above it)?  I need to apply in incremental patch in the
> merge commit.

I don't think I touched the comment at all.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 12:19 ` Peter Zijlstra
  2014-01-16 20:46   ` Stephen Rothwell
@ 2014-01-16 20:56   ` H. Peter Anvin
  1 sibling, 0 replies; 357+ messages in thread
From: H. Peter Anvin @ 2014-01-16 20:56 UTC (permalink / raw)
  To: Peter Zijlstra, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Len Brown, linux-next, linux-kernel

On 01/16/2014 04:19 AM, Peter Zijlstra wrote:
> + * MONITOR/MWAIT with no hints, used for default default C1 state.

The default default?

	-hpa

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16 12:19 ` Peter Zijlstra
@ 2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 22:25     ` Peter Zijlstra
  2014-01-20  4:45     ` Len Brown
  2014-01-16 20:56   ` H. Peter Anvin
  1 sibling, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-16 20:46 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Hi Peter,

On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> I think the below ought to work

To be clear, all you did was replace the body of mwait_idle() with

	mwait_idle_with_hints(0, 0);

(and the comment above it)?  I need to apply in incremental patch in the
merge commit.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-16  3:58 Stephen Rothwell
@ 2014-01-16 12:19 ` Peter Zijlstra
  2014-01-16 20:46   ` Stephen Rothwell
  2014-01-16 20:56   ` H. Peter Anvin
  2014-01-20  1:00 ` Len Brown
  1 sibling, 2 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-16 12:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Len Brown,
	linux-next, linux-kernel

On Thu, Jan 16, 2014 at 02:58:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
>    __monitor((void *)&current_thread_info()->flags, 0, 0);
>    ^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
>     __sti_mwait(0, 0);
>     ^
> 
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
> 
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.

I think the below ought to work

---
 arch/x86/kernel/process.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8b5..220df9b2f22a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/mwait.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -398,6 +399,37 @@ static void amd_e400_idle(void)
 		default_idle();
 }
 
+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *  
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+	if (c->x86_vendor != X86_VENDOR_INTEL)
+		return 0;
+
+	if (!cpu_has(c, X86_FEATURE_MWAIT))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+static void mwait_idle(void)
+{
+	mwait_idle_with_hints(0, 0);
+}
+
 void select_idle_routine(const struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
@@ -411,6 +443,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c)
 		/* E400: APIC timer interrupt does not wake up CPU from C1e */
 		pr_info("using AMD E400 aware idle routine\n");
 		x86_idle = amd_e400_idle;
+	} else if (prefer_mwait_c1_over_halt(c)) {
+		pr_info("using mwait in idle threads\n");
+		x86_idle = mwait_idle;
 	} else
 		x86_idle = default_idle;
 }

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:43       ` Mikulas Patocka
  2014-01-14 22:03         ` Rafael J. Wysocki
@ 2014-01-16 12:14         ` Peter Zijlstra
  1 sibling, 0 replies; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-16 12:14 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, Viresh Kumar, linux-next, linux-kernel,
	cpufreq

On Tue, Jan 14, 2014 at 04:43:43PM -0500, Mikulas Patocka wrote:
> > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> >  		if (retry) {
> >  			pr_debug("retry %u, previous result %u, waiting...\n",
> >  					retry, result);
> > +			local_irq_restore(flags);
> 
> ^^^ this is wrong, because the function speedstep_set_state may already be 
> called with interrupts disabled from speedstep_get_freqs. So, you need to 
> enable interrupts unconditionally, even if they were disabled at the 
> beginning of the function speedstep_set_state.
> 
> I know it's dirty to enable interrupts in a function that was called with 
> disabled interrupts, but here it must be so (you could rewrite 
> speedstep_get_freqs to not disable interrupts if you want to avoid this 
> dirtiness).

Egads; I think you had better, this is vile beyond reason.

> >  			mdelay(retry * 50);
> > +			local_irq_save(flags);
> >  		}
> >  		retry++;
> >  		__asm__ __volatile__(
> > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> >  
> >  	/* enable IRQs */
> >  	local_irq_restore(flags);
> > +	preempt_enable();
> >  
> >  	if (new_state == state)
> >  		pr_debug("change to %u MHz succeeded after %u tries "
> 
> You need also preempt_disable/enable in speedstep_get_freqs.

Argh I see, this is really horrid.


Anyway, its Rafael's call, its his subsystem he gets to fix it when it
explodes.

/me shudders

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-01-16  3:58 Stephen Rothwell
  2014-01-16 12:19 ` Peter Zijlstra
  2014-01-20  1:00 ` Len Brown
  0 siblings, 2 replies; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-16  3:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Len Brown
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kernel/process.c: In function 'mwait_idle':
/scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit declaration of function '__monitor' [-Werror=implicit-function-declaration]
   __monitor((void *)&current_thread_info()->flags, 0, 0);
   ^
arch/x86/kernel/process.c:437:4: error: implicit declaration of function '__sti_mwait' [-Werror=implicit-function-declaration]
    __sti_mwait(0, 0);
    ^

Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
mwait_idle()") from the idle tree.

I am not sure how to fix this so I just reverted the idle tree commit for
now (since it reverted cleanly). Please let me know if there is a better
solution.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:52           ` Mikulas Patocka
@ 2014-01-14 22:18             ` Rafael J. Wysocki
  0 siblings, 0 replies; 357+ messages in thread
From: Rafael J. Wysocki @ 2014-01-14 22:18 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq

On Tuesday, January 14, 2014 04:52:20 PM Mikulas Patocka wrote:
> 
> On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:
> 
> > On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> > > 
> > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > 
> > > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > > preempt_enable_no_resched() from modules")
> > > > 
> > > > Read these two lines, then note that:
> > > > 
> > > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > > > 
> > > > this obviously will not work as preempt_check_resched() and
> > > > preempt_enable_no_resched() are no longer available to modules.
> > > 
> > > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> > > linux-next, that broke my patch.
> > > 
> > > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > > patch is a very good idea.
> > > > > > 
> > > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > > interrupt is required for progress, and how does it make the progress
> > > > > > happen.
> > > > > 
> > > > > There is no explanation. It's hardware issue and I have no documentation 
> > > > > for the hardware.
> > > > 
> > > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > > hardware does/needs.
> > > > 
> > > > > The general problem is that if there are bus-master transfers running (or 
> > > > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > > > You can wait a little bit and retry and maybe you succeed changing the 
> > > > > frequency next time.
> > > > > 
> > > > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > > > matter how long do you wait. I found it experimentally, I don't know 
> > > > > reason for that.
> > > > 
> > > > Sounds like magic goo..
> > > > 
> > > > In any case, try the below, it does the same but is far less horrid.
> > > > 
> > > > ---
> > > >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > > index 0f5326d6f79f..57d31538c248 100644
> > > > --- a/drivers/cpufreq/speedstep-smi.c
> > > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > > >  		return;
> > > >  
> > > >  	/* Disable IRQs */
> > > > +	preempt_disable();
> > > >  	local_irq_save(flags);
> > > >  
> > > >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > > >  		if (retry) {
> > > >  			pr_debug("retry %u, previous result %u, waiting...\n",
> > > >  					retry, result);
> > > > +			local_irq_restore(flags);
> > > 
> > > ^^^ this is wrong, because the function speedstep_set_state may already be 
> > > called with interrupts disabled from speedstep_get_freqs. So, you need to 
> > > enable interrupts unconditionally, even if they were disabled at the 
> > > beginning of the function speedstep_set_state.
> > > 
> > > I know it's dirty to enable interrupts in a function that was called with 
> > > disabled interrupts, but here it must be so (you could rewrite 
> > > speedstep_get_freqs to not disable interrupts if you want to avoid this 
> > > dirtiness).
> > > 
> > > >  			mdelay(retry * 50);
> > > > +			local_irq_save(flags);
> > > >  		}
> > > >  		retry++;
> > > >  		__asm__ __volatile__(
> > > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > > >  
> > > >  	/* enable IRQs */
> > > >  	local_irq_restore(flags);
> > > > +	preempt_enable();
> > > >  
> > > >  	if (new_state == state)
> > > >  		pr_debug("change to %u MHz succeeded after %u tries "
> > > 
> > > You need also preempt_disable/enable in speedstep_get_freqs.
> > > 
> > > 
> > > Here I'm resending the patch, to account for 
> > > 62b94a08da1bae9d187d49dfcd6665af393750f8.
> > 
> > Do I think correctly that this should work regardless of whether or not
> > 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?
> 
> Yes.

OK

I'll replace your original patch with this version, then.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 21:43       ` Mikulas Patocka
@ 2014-01-14 22:03         ` Rafael J. Wysocki
  2014-01-14 21:52           ` Mikulas Patocka
  2014-01-16 12:14         ` Peter Zijlstra
  1 sibling, 1 reply; 357+ messages in thread
From: Rafael J. Wysocki @ 2014-01-14 22:03 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq

On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> 
> On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> 
> > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > preempt_enable_no_resched() from modules")
> > 
> > Read these two lines, then note that:
> > 
> > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > 
> > this obviously will not work as preempt_check_resched() and
> > preempt_enable_no_resched() are no longer available to modules.
> 
> I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> linux-next, that broke my patch.
> 
> > > > I think that pm commit is a very good example of why the sched/preempt
> > > > patch is a very good idea.
> > > > 
> > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > interrupt is required for progress, and how does it make the progress
> > > > happen.
> > > 
> > > There is no explanation. It's hardware issue and I have no documentation 
> > > for the hardware.
> > 
> > Rafael works for Intel, he ought to be able to figure out wtf the
> > hardware does/needs.
> > 
> > > The general problem is that if there are bus-master transfers running (or 
> > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > You can wait a little bit and retry and maybe you succeed changing the 
> > > frequency next time.
> > > 
> > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > matter how long do you wait. I found it experimentally, I don't know 
> > > reason for that.
> > 
> > Sounds like magic goo..
> > 
> > In any case, try the below, it does the same but is far less horrid.
> > 
> > ---
> >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > index 0f5326d6f79f..57d31538c248 100644
> > --- a/drivers/cpufreq/speedstep-smi.c
> > +++ b/drivers/cpufreq/speedstep-smi.c
> > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> >  		return;
> >  
> >  	/* Disable IRQs */
> > +	preempt_disable();
> >  	local_irq_save(flags);
> >  
> >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> >  		if (retry) {
> >  			pr_debug("retry %u, previous result %u, waiting...\n",
> >  					retry, result);
> > +			local_irq_restore(flags);
> 
> ^^^ this is wrong, because the function speedstep_set_state may already be 
> called with interrupts disabled from speedstep_get_freqs. So, you need to 
> enable interrupts unconditionally, even if they were disabled at the 
> beginning of the function speedstep_set_state.
> 
> I know it's dirty to enable interrupts in a function that was called with 
> disabled interrupts, but here it must be so (you could rewrite 
> speedstep_get_freqs to not disable interrupts if you want to avoid this 
> dirtiness).
> 
> >  			mdelay(retry * 50);
> > +			local_irq_save(flags);
> >  		}
> >  		retry++;
> >  		__asm__ __volatile__(
> > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> >  
> >  	/* enable IRQs */
> >  	local_irq_restore(flags);
> > +	preempt_enable();
> >  
> >  	if (new_state == state)
> >  		pr_debug("change to %u MHz succeeded after %u tries "
> 
> You need also preempt_disable/enable in speedstep_get_freqs.
> 
> 
> Here I'm resending the patch, to account for 
> 62b94a08da1bae9d187d49dfcd6665af393750f8.

Do I think correctly that this should work regardless of whether or not
62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?

> From: Mikulas Patocka <mpatocka@redhat.com>
> 
> speedstep-smi: enable interrupts when waiting
> 
> On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
> speedstep-smi driver sometimes loads and sometimes doesn't load with
> "change to state X failed" message.
> 
> I found out that we need to enable interrupts while waiting. When we
> enable interrupts, the blockage that prevents frequency transition
> resolves and the transition is possible. With disabled interrupts, the
> blockage doesn't resolve (no matter how long do we wait).
> 
> This patch enables interrupts in the function speedstep_set_state that can
> be called with disabled interrupts. However, this function is called with
> disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
> any problem.
> 
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> 
> ---
>  drivers/cpufreq/speedstep-lib.c |    3 +++
>  drivers/cpufreq/speedstep-smi.c |   12 ++++++++++++
>  2 files changed, 15 insertions(+)
> 
> Index: linux-next/drivers/cpufreq/speedstep-smi.c
> ===================================================================
> --- linux-next.orig/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:26:59.000000000 +0100
> +++ linux-next/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:35:11.000000000 +0100
> @@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned
>  		return;
>  
>  	/* Disable IRQs */
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> @@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned
>  
>  	do {
>  		if (retry) {
> +			/*
> +			 * We need to enable interrupts, otherwise the blockage
> +			 * won't resolve.
> +			 *
> +			 * We disable preemption so that other processes don't
> +			 * run. If other processes were running, they could
> +			 * submit more DMA requests, making the blockage worse.
> +			 */
>  			pr_debug("retry %u, previous result %u, waiting...\n",
>  					retry, result);
> +			local_irq_enable();
>  			mdelay(retry * 50);
> +			local_irq_disable();
>  		}
>  		retry++;
>  		__asm__ __volatile__(
> @@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned
>  
>  	/* enable IRQs */
>  	local_irq_restore(flags);
> +	preempt_enable();
>  
>  	if (new_state == state)
>  		pr_debug("change to %u MHz succeeded after %u tries "
> Index: linux-next/drivers/cpufreq/speedstep-lib.c
> ===================================================================
> --- linux-next.orig/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:29:07.000000000 +0100
> +++ linux-next/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:31:04.000000000 +0100
> @@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp
>  
>  	pr_debug("previous speed is %u\n", prev_speed);
>  
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	/* switch to low state */
> @@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp
>  
>  out:
>  	local_irq_restore(flags);
> +	preempt_enable();
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(speedstep_get_freqs);
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 22:03         ` Rafael J. Wysocki
@ 2014-01-14 21:52           ` Mikulas Patocka
  2014-01-14 22:18             ` Rafael J. Wysocki
  0 siblings, 1 reply; 357+ messages in thread
From: Mikulas Patocka @ 2014-01-14 21:52 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Peter Zijlstra, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Viresh Kumar, linux-next, linux-kernel, cpufreq



On Tue, 14 Jan 2014, Rafael J. Wysocki wrote:

> On Tuesday, January 14, 2014 04:43:43 PM Mikulas Patocka wrote:
> > 
> > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > 
> > > On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > > > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > > > preempt_enable_no_resched() from modules")
> > > 
> > > Read these two lines, then note that:
> > > 
> > > > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> > > 
> > > this obviously will not work as preempt_check_resched() and
> > > preempt_enable_no_resched() are no longer available to modules.
> > 
> > I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
> > linux-next, that broke my patch.
> > 
> > > > > I think that pm commit is a very good example of why the sched/preempt
> > > > > patch is a very good idea.
> > > > > 
> > > > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > > > interrupt is required for progress, and how does it make the progress
> > > > > happen.
> > > > 
> > > > There is no explanation. It's hardware issue and I have no documentation 
> > > > for the hardware.
> > > 
> > > Rafael works for Intel, he ought to be able to figure out wtf the
> > > hardware does/needs.
> > > 
> > > > The general problem is that if there are bus-master transfers running (or 
> > > > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > > > You can wait a little bit and retry and maybe you succeed changing the 
> > > > frequency next time.
> > > > 
> > > > If you enable interrupts, wait, disable interrupts and retry, you may 
> > > > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > > > matter how long do you wait. I found it experimentally, I don't know 
> > > > reason for that.
> > > 
> > > Sounds like magic goo..
> > > 
> > > In any case, try the below, it does the same but is far less horrid.
> > > 
> > > ---
> > >  drivers/cpufreq/speedstep-smi.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> > > index 0f5326d6f79f..57d31538c248 100644
> > > --- a/drivers/cpufreq/speedstep-smi.c
> > > +++ b/drivers/cpufreq/speedstep-smi.c
> > > @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
> > >  		return;
> > >  
> > >  	/* Disable IRQs */
> > > +	preempt_disable();
> > >  	local_irq_save(flags);
> > >  
> > >  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> > > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > >  		if (retry) {
> > >  			pr_debug("retry %u, previous result %u, waiting...\n",
> > >  					retry, result);
> > > +			local_irq_restore(flags);
> > 
> > ^^^ this is wrong, because the function speedstep_set_state may already be 
> > called with interrupts disabled from speedstep_get_freqs. So, you need to 
> > enable interrupts unconditionally, even if they were disabled at the 
> > beginning of the function speedstep_set_state.
> > 
> > I know it's dirty to enable interrupts in a function that was called with 
> > disabled interrupts, but here it must be so (you could rewrite 
> > speedstep_get_freqs to not disable interrupts if you want to avoid this 
> > dirtiness).
> > 
> > >  			mdelay(retry * 50);
> > > +			local_irq_save(flags);
> > >  		}
> > >  		retry++;
> > >  		__asm__ __volatile__(
> > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > >  
> > >  	/* enable IRQs */
> > >  	local_irq_restore(flags);
> > > +	preempt_enable();
> > >  
> > >  	if (new_state == state)
> > >  		pr_debug("change to %u MHz succeeded after %u tries "
> > 
> > You need also preempt_disable/enable in speedstep_get_freqs.
> > 
> > 
> > Here I'm resending the patch, to account for 
> > 62b94a08da1bae9d187d49dfcd6665af393750f8.
> 
> Do I think correctly that this should work regardless of whether or not
> 62b94a08da1bae9d187d49dfcd6665af393750f8 is applied?

Yes.

Mikulas

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 20:05     ` Peter Zijlstra
@ 2014-01-14 21:43       ` Mikulas Patocka
  2014-01-14 22:03         ` Rafael J. Wysocki
  2014-01-16 12:14         ` Peter Zijlstra
  0 siblings, 2 replies; 357+ messages in thread
From: Mikulas Patocka @ 2014-01-14 21:43 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, Viresh Kumar, linux-next, linux-kernel,
	cpufreq



On Tue, 14 Jan 2014, Peter Zijlstra wrote:

> On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> > On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > > preempt_enable_no_resched() from modules")
> 
> Read these two lines, then note that:
> 
> > Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> 
> this obviously will not work as preempt_check_resched() and
> preempt_enable_no_resched() are no longer available to modules.

I see, you added commit 62b94a08da1bae9d187d49dfcd6665af393750f8 to 
linux-next, that broke my patch.

> > > I think that pm commit is a very good example of why the sched/preempt
> > > patch is a very good idea.
> > > 
> > > Also that Changelog fails to explain why enabling interrupts helps. What
> > > interrupt is required for progress, and how does it make the progress
> > > happen.
> > 
> > There is no explanation. It's hardware issue and I have no documentation 
> > for the hardware.
> 
> Rafael works for Intel, he ought to be able to figure out wtf the
> hardware does/needs.
> 
> > The general problem is that if there are bus-master transfers running (or 
> > possibly for other hardware reasons), the CPU refuses to change frequency. 
> > You can wait a little bit and retry and maybe you succeed changing the 
> > frequency next time.
> > 
> > If you enable interrupts, wait, disable interrupts and retry, you may 
> > succeed. If you keep interrupts disabled and retry, you never succeed, no 
> > matter how long do you wait. I found it experimentally, I don't know 
> > reason for that.
> 
> Sounds like magic goo..
> 
> In any case, try the below, it does the same but is far less horrid.
> 
> ---
>  drivers/cpufreq/speedstep-smi.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> index 0f5326d6f79f..57d31538c248 100644
> --- a/drivers/cpufreq/speedstep-smi.c
> +++ b/drivers/cpufreq/speedstep-smi.c
> @@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
>  		return;
>  
>  	/* Disable IRQs */
> +	preempt_disable();
>  	local_irq_save(flags);
>  
>  	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
> @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
>  		if (retry) {
>  			pr_debug("retry %u, previous result %u, waiting...\n",
>  					retry, result);
> +			local_irq_restore(flags);

^^^ this is wrong, because the function speedstep_set_state may already be 
called with interrupts disabled from speedstep_get_freqs. So, you need to 
enable interrupts unconditionally, even if they were disabled at the 
beginning of the function speedstep_set_state.

I know it's dirty to enable interrupts in a function that was called with 
disabled interrupts, but here it must be so (you could rewrite 
speedstep_get_freqs to not disable interrupts if you want to avoid this 
dirtiness).

>  			mdelay(retry * 50);
> +			local_irq_save(flags);
>  		}
>  		retry++;
>  		__asm__ __volatile__(
> @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
>  
>  	/* enable IRQs */
>  	local_irq_restore(flags);
> +	preempt_enable();
>  
>  	if (new_state == state)
>  		pr_debug("change to %u MHz succeeded after %u tries "

You need also preempt_disable/enable in speedstep_get_freqs.


Here I'm resending the patch, to account for 
62b94a08da1bae9d187d49dfcd6665af393750f8.



From: Mikulas Patocka <mpatocka@redhat.com>

speedstep-smi: enable interrupts when waiting

On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
speedstep-smi driver sometimes loads and sometimes doesn't load with
"change to state X failed" message.

I found out that we need to enable interrupts while waiting. When we
enable interrupts, the blockage that prevents frequency transition
resolves and the transition is possible. With disabled interrupts, the
blockage doesn't resolve (no matter how long do we wait).

This patch enables interrupts in the function speedstep_set_state that can
be called with disabled interrupts. However, this function is called with
disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
any problem.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 drivers/cpufreq/speedstep-lib.c |    3 +++
 drivers/cpufreq/speedstep-smi.c |   12 ++++++++++++
 2 files changed, 15 insertions(+)

Index: linux-next/drivers/cpufreq/speedstep-smi.c
===================================================================
--- linux-next.orig/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:26:59.000000000 +0100
+++ linux-next/drivers/cpufreq/speedstep-smi.c	2014-01-14 22:35:11.000000000 +0100
@@ -156,6 +156,7 @@ static void speedstep_set_state(unsigned
 		return;
 
 	/* Disable IRQs */
+	preempt_disable();
 	local_irq_save(flags);
 
 	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
@@ -166,9 +167,19 @@ static void speedstep_set_state(unsigned
 
 	do {
 		if (retry) {
+			/*
+			 * We need to enable interrupts, otherwise the blockage
+			 * won't resolve.
+			 *
+			 * We disable preemption so that other processes don't
+			 * run. If other processes were running, they could
+			 * submit more DMA requests, making the blockage worse.
+			 */
 			pr_debug("retry %u, previous result %u, waiting...\n",
 					retry, result);
+			local_irq_enable();
 			mdelay(retry * 50);
+			local_irq_disable();
 		}
 		retry++;
 		__asm__ __volatile__(
@@ -185,6 +196,7 @@ static void speedstep_set_state(unsigned
 
 	/* enable IRQs */
 	local_irq_restore(flags);
+	preempt_enable();
 
 	if (new_state == state)
 		pr_debug("change to %u MHz succeeded after %u tries "
Index: linux-next/drivers/cpufreq/speedstep-lib.c
===================================================================
--- linux-next.orig/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:29:07.000000000 +0100
+++ linux-next/drivers/cpufreq/speedstep-lib.c	2014-01-14 22:31:04.000000000 +0100
@@ -400,6 +400,7 @@ unsigned int speedstep_get_freqs(enum sp
 
 	pr_debug("previous speed is %u\n", prev_speed);
 
+	preempt_disable();
 	local_irq_save(flags);
 
 	/* switch to low state */
@@ -464,6 +465,8 @@ unsigned int speedstep_get_freqs(enum sp
 
 out:
 	local_irq_restore(flags);
+	preempt_enable();
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 19:06   ` Mikulas Patocka
@ 2014-01-14 20:05     ` Peter Zijlstra
  2014-01-14 21:43       ` Mikulas Patocka
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-14 20:05 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, linux-next, linux-kernel

On Tue, Jan 14, 2014 at 02:06:57PM -0500, Mikulas Patocka wrote:
> On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> > > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > > preempt_enable_no_resched() from modules")

Read these two lines, then note that:

> Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?

this obviously will not work as preempt_check_resched() and
preempt_enable_no_resched() are no longer available to modules.

> > I think that pm commit is a very good example of why the sched/preempt
> > patch is a very good idea.
> > 
> > Also that Changelog fails to explain why enabling interrupts helps. What
> > interrupt is required for progress, and how does it make the progress
> > happen.
> 
> There is no explanation. It's hardware issue and I have no documentation 
> for the hardware.

Rafael works for Intel, he ought to be able to figure out wtf the
hardware does/needs.

> The general problem is that if there are bus-master transfers running (or 
> possibly for other hardware reasons), the CPU refuses to change frequency. 
> You can wait a little bit and retry and maybe you succeed changing the 
> frequency next time.
> 
> If you enable interrupts, wait, disable interrupts and retry, you may 
> succeed. If you keep interrupts disabled and retry, you never succeed, no 
> matter how long do you wait. I found it experimentally, I don't know 
> reason for that.

Sounds like magic goo..

In any case, try the below, it does the same but is far less horrid.

---
 drivers/cpufreq/speedstep-smi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 0f5326d6f79f..57d31538c248 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -188,6 +188,7 @@ static void speedstep_set_state(unsigned int state)
 		return;
 
 	/* Disable IRQs */
+	preempt_disable();
 	local_irq_save(flags);
 
 	command = (smi_sig & 0xffffff00) | (smi_cmd & 0xff);
@@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
 		if (retry) {
 			pr_debug("retry %u, previous result %u, waiting...\n",
 					retry, result);
+			local_irq_restore(flags);
 			mdelay(retry * 50);
+			local_irq_save(flags);
 		}
 		retry++;
 		__asm__ __volatile__(
@@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
 
 	/* enable IRQs */
 	local_irq_restore(flags);
+	preempt_enable();
 
 	if (new_state == state)
 		pr_debug("change to %u MHz succeeded after %u tries "

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14 14:14 ` Peter Zijlstra
@ 2014-01-14 19:06   ` Mikulas Patocka
  2014-01-14 20:05     ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: Mikulas Patocka @ 2014-01-14 19:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Rafael J. Wysocki, linux-next, linux-kernel



On Tue, 14 Jan 2014, Peter Zijlstra wrote:

> On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> > drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
> >   preempt_check_resched();
> >   ^
> > 
> > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > preempt_enable_no_resched() from modules") interacting with commit
> > 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> > pm tree.

Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?

> I think that pm commit is a very good example of why the sched/preempt
> patch is a very good idea.
> 
> Also that Changelog fails to explain why enabling interrupts helps. What
> interrupt is required for progress, and how does it make the progress
> happen.

There is no explanation. It's hardware issue and I have no documentation 
for the hardware.


The general problem is that if there are bus-master transfers running (or 
possibly for other hardware reasons), the CPU refuses to change frequency. 
You can wait a little bit and retry and maybe you succeed changing the 
frequency next time.

If you enable interrupts, wait, disable interrupts and retry, you may 
succeed. If you keep interrupts disabled and retry, you never succeed, no 
matter how long do you wait. I found it experimentally, I don't know 
reason for that.

Mikulas

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2014-01-14  3:26 Stephen Rothwell
@ 2014-01-14 14:14 ` Peter Zijlstra
  2014-01-14 19:06   ` Mikulas Patocka
  0 siblings, 1 reply; 357+ messages in thread
From: Peter Zijlstra @ 2014-01-14 14:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Rafael J. Wysocki,
	linux-next, linux-kernel, Mikulas Patocka

On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
>   preempt_check_resched();
>   ^
> 
> Caused by commit 62b94a08da1b ("sched/preempt: Take away
> preempt_enable_no_resched() from modules") interacting with commit
> 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> pm tree.

I think that pm commit is a very good example of why the sched/preempt
patch is a very good idea.

Also that Changelog fails to explain why enabling interrupts helps. What
interrupt is required for progress, and how does it make the progress
happen.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2014-01-14  3:26 Stephen Rothwell
  2014-01-14 14:14 ` Peter Zijlstra
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2014-01-14  3:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Mikulas Patocka

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
  preempt_check_resched();
  ^

Caused by commit 62b94a08da1b ("sched/preempt: Take away
preempt_enable_no_resched() from modules") interacting with commit
24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
pm tree.

For now, I have reverted that pm tree commit.  Please sort this out.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28 10:26   ` Ingo Molnar
@ 2013-10-29  6:00     ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2013-10-29  6:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thierry Reding, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

Hi Ingo,

On Mon, 28 Oct 2013 11:26:04 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thierry Reding <thierry.reding@gmail.com> wrote:
> 
> > On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
> > >                  from /scratch/sfr/next/include/linux/gfp.h:4,
> > >                  from /scratch/sfr/next/include/linux/kmod.h:22,
> > >                  from /scratch/sfr/next/include/linux/module.h:13,
> > >                  from /scratch/sfr/next/block/blk-mq.c:2:
> > > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> > > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
> > >   __ret;        \
> > >   ^
> > > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
> > >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > >         ^
> > > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
> > >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> > >       ^
> > > 
> > > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> > > interface more friendly").
> > > 
> > > Since this was also in next-20131025, I applied the following merge fix
> > > commit for today, please fix this in the tip tree.
> > 
> > FWIW I got confirmation on Oct 23 that this had been committed to the
> > tip tree. So I guess it just wasn't pushed yet.
> 
> I merged the fix intoo the linux-next branch earlier today so it 
> should be resolved soon.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28 10:18 ` Thierry Reding
@ 2013-10-28 10:26   ` Ingo Molnar
  2013-10-29  6:00     ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Ingo Molnar @ 2013-10-28 10:26 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel


* Thierry Reding <thierry.reding@gmail.com> wrote:

> On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
> >                  from /scratch/sfr/next/include/linux/gfp.h:4,
> >                  from /scratch/sfr/next/include/linux/kmod.h:22,
> >                  from /scratch/sfr/next/include/linux/module.h:13,
> >                  from /scratch/sfr/next/block/blk-mq.c:2:
> > /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> > /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
> >   __ret;        \
> >   ^
> > /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
> >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> >         ^
> > /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
> >   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
> >       ^
> > 
> > Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> > interface more friendly").
> > 
> > Since this was also in next-20131025, I applied the following merge fix
> > commit for today, please fix this in the tip tree.
> 
> FWIW I got confirmation on Oct 23 that this had been committed to the
> tip tree. So I guess it just wasn't pushed yet.

I merged the fix intoo the linux-next branch earlier today so it 
should be resolved soon.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-10-28  9:24 Stephen Rothwell
@ 2013-10-28 10:18 ` Thierry Reding
  2013-10-28 10:26   ` Ingo Molnar
  0 siblings, 1 reply; 357+ messages in thread
From: Thierry Reding @ 2013-10-28 10:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Mon, Oct 28, 2013 at 08:24:42PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
>                  from /scratch/sfr/next/include/linux/gfp.h:4,
>                  from /scratch/sfr/next/include/linux/kmod.h:22,
>                  from /scratch/sfr/next/include/linux/module.h:13,
>                  from /scratch/sfr/next/block/blk-mq.c:2:
> /scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
> /scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
>   __ret;        \
>   ^
> /scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
>   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
>         ^
> /scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
>   ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
>       ^
> 
> Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
> interface more friendly").
> 
> Since this was also in next-20131025, I applied the following merge fix
> commit for today, please fix this in the tip tree.

FWIW I got confirmation on Oct 23 that this had been committed to the
tip tree. So I guess it just wasn't pushed yet.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-10-28  9:24 Stephen Rothwell
  2013-10-28 10:18 ` Thierry Reding
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2013-10-28  9:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from /scratch/sfr/next/include/linux/mmzone.h:9:0,
                 from /scratch/sfr/next/include/linux/gfp.h:4,
                 from /scratch/sfr/next/include/linux/kmod.h:22,
                 from /scratch/sfr/next/include/linux/module.h:13,
                 from /scratch/sfr/next/block/blk-mq.c:2:
/scratch/sfr/next/block/blk-mq.c: In function 'blk_mq_queue_enter':
/scratch/sfr/next/include/linux/wait.h:772:2: error: expected ';' before '__ret'
  __ret;        \
  ^
/scratch/sfr/next/block/blk-mq.c:108:8: note: in expansion of macro 'wait_event_interruptible_lock_irq'
  ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
        ^
/scratch/sfr/next/block/blk-mq.c:108:6: error: void value not ignored as it ought to be
  ret = wait_event_interruptible_lock_irq(q->mq_freeze_wq,
      ^

Caused by commit 35a2af94c7ce ("sched/wait: Make the __wait_event*()
interface more friendly").

Since this was also in next-20131025, I applied the following merge fix
commit for today, please fix this in the tip tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Oct 2013 20:19:27 +1100
Subject: [PATCH] sched/wait: fix missing semicolon

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/wait.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 7f8caa519128..fcc968087f05 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -768,7 +768,7 @@ do {									\
 	int __ret = 0;							\
 	if (!(condition))						\
 		__ret = __wait_event_interruptible_lock_irq(wq,		\
-						condition, lock,)	\
+						condition, lock,);	\
 	__ret;								\
 })
 
-- 
1.8.4.rc3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-04-29  5:45 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2013-04-29  5:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Tom Gundersen, Matt Fleming

[-- Attachment #1: Type: text/plain, Size: 6151 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/firmware/efi/efivars.c: In function 'efivar_release':
drivers/firmware/efi/efivars.c:300:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efivars.c: In function 'efivar_create':
drivers/firmware/efi/efivars.c:341:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efivars.c:341:12: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivar_create_sysfs_entry':
drivers/firmware/efi/efivars.c:420:13: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'create_efivars_bin_attributes':
drivers/firmware/efi/efivars.c:460:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c:470:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivar_update_sysfs_entries':
drivers/firmware/efi/efivars.c:527:8: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efivars.c: In function 'efivars_sysfs_callback':
drivers/firmware/efi/efivars.c:551:8: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/inode.c: In function 'efivarfs_create':
fs/efivarfs/inode.c:115:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/inode.c:115:6: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/inode.c:139:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c: In function 'efivarfs_file_write':
fs/efivarfs/file.c:35:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c:35:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/file.c:62:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
fs/efivarfs/file.c: In function 'efivarfs_file_read':
fs/efivarfs/file.c:81:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c: In function 'efivarfs_callback':
fs/efivarfs/super.c:132:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
fs/efivarfs/super.c:132:8: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c:142:7: warning: assignment makes pointer from integer without a cast [enabled by default]
fs/efivarfs/super.c:166:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efi-pstore.c: In function 'efi_pstore_read_func':
drivers/firmware/efi/efi-pstore.c:77:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
drivers/firmware/efi/efi-pstore.c:77:16: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/firmware/efi/efi-pstore.c: In function 'efivars_pstore_init':
drivers/firmware/efi/efi-pstore.c:225:22: warning: assignment makes pointer from integer without a cast [enabled by default]

Probably caused by commits d68772b7c83f ("efivarfs: Move to fs/efivarfs")
and/or a9499fa7cd3f ("efi: split efisubsystem from efivars") interacting
with some header inclusion changes in the rest of today's trees.

See Rule 1 from Documentation/SubmitChecklist.

I have applied the following merge fix patch for today (this won't quite
apply to the tip tree due to the other patch adding linux/magic.h to
fs/efivarfs/super.c, but that could be applied as well):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Apr 2013 15:34:28 +1000
Subject: [PATCH] efivars: use of kmalloc etc requires the inclusion of slab.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/firmware/efi/efivars.c | 1 +
 fs/efivarfs/file.c             | 1 +
 fs/efivarfs/inode.c            | 1 +
 fs/efivarfs/super.c            | 1 +
 drivers/firmware/efi/efi-pstore.c | 1 +
 5 files changed, 5 insertions(+)

diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c
index f8f5e5d..66928a3 100644
--- a/drivers/firmware/efi/efivars.c
+++ b/drivers/firmware/efi/efivars.c
@@ -68,6 +68,7 @@
 #include <linux/efi.h>
 #include <linux/module.h>
 #include <linux/ucs2_string.h>
+#include <linux/slab.h>
 
 #define EFIVARS_VERSION "0.08"
 #define EFIVARS_DATE "2004-May-17"
diff --git a/fs/efivarfs/file.c b/fs/efivarfs/file.c
index ede07fc..bfb5315 100644
--- a/fs/efivarfs/file.c
+++ b/fs/efivarfs/file.c
@@ -9,6 +9,7 @@
 
 #include <linux/efi.h>
 #include <linux/fs.h>
+#include <linux/slab.h>
 
 #include "internal.h"
 
diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c
index 640e289..7e787fb 100644
--- a/fs/efivarfs/inode.c
+++ b/fs/efivarfs/inode.c
@@ -10,6 +10,7 @@
 #include <linux/efi.h>
 #include <linux/fs.h>
 #include <linux/ctype.h>
+#include <linux/slab.h>
 
 #include "internal.h"
 
diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 1fa5e6d..94d9192 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -12,6 +12,7 @@
 #include <linux/fs.h>
 #include <linux/module.h>
 #include <linux/pagemap.h>
+#include <linux/slab.h>
 #include <linux/magic.h>
 
 #include "internal.h"
diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c
index 221ad1b..0242795 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -2,6 +2,7 @@
 #include <linux/module.h>
 #include <linux/pstore.h>
 #include <linux/ucs2_string.h>
+#include <linux/slab.h>
 
 #define DUMP_NAME_LEN 52
 

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2013-02-14  2:30 Stephen Rothwell
@ 2013-02-21  2:04 ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2013-02-21  2:04 UTC (permalink / raw)
  To: Zhang Rui
  Cc: linux-next, linux-kernel, Jacob Pan, Arjan van de Ven,
	Clark Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Hi all,

On Thu, 14 Feb 2013 13:30:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/thermal/intel_powerclamp.c: In function 'clamp_thread':
> drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function)
> 
> Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new
> header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel
> PowerClamp Driver") from the thermal tree.
> 
> I applied this merge fix patch and can carry it as necessary:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 14 Feb 2013 13:26:22 +1100
> Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/thermal/intel_powerclamp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
> index ab3ed90..b40b37c 100644
> --- a/drivers/thermal/intel_powerclamp.c
> +++ b/drivers/thermal/intel_powerclamp.c
> @@ -50,6 +50,7 @@
>  #include <linux/tick.h>
>  #include <linux/debugfs.h>
>  #include <linux/seq_file.h>
> +#include <linux/sched/rt.h>
>  
>  #include <asm/nmi.h>
>  #include <asm/msr.h>

The above fix is now needed when the thermal tree is merged with Linus'
tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-02-14  2:30 Stephen Rothwell
  2013-02-21  2:04 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2013-02-14  2:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jacob Pan, Arjan van de Ven, Zhang Rui,
	Clark Williams

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/thermal/intel_powerclamp.c: In function 'clamp_thread':
drivers/thermal/intel_powerclamp.c:360:21: error: 'MAX_USER_RT_PRIO' undeclared (first use in this function)

Caused by commit 8bd75c77b7c6 ("sched/rt: Move rt specific bits into new
header file") interacting with commit d6d71ee4a14a ("PM: Introduce Intel
PowerClamp Driver") from the thermal tree.

I applied this merge fix patch and can carry it as necessary:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 14 Feb 2013 13:26:22 +1100
Subject: [PATCH] sched/rt: fix PowerClamp Driver for define move

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/thermal/intel_powerclamp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
index ab3ed90..b40b37c 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -50,6 +50,7 @@
 #include <linux/tick.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/sched/rt.h>
 
 #include <asm/nmi.h>
 #include <asm/msr.h>
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2013-02-02  5:04 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2013-02-02  5:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Sukadev Bhattiprolu, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 'power7_events_attr[0]') [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 'power7_events_attr[1]') [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 'power7_events_attr[2]') [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 'power7_events_attr[3]') [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 'power7_events_attr[4]') [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 'power7_events_attr[5]') [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 'power7_events_attr[6]') [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 'power7_events_attr[7]') [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 'power7_events_attr[8]') [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 'power7_events_attr[9]') [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 'power7_events_attr[10]') [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 'power7_events_attr[11]') [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 'power7_events_attr[12]') [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 'power7_events_attr[13]') [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 'power7_events_attr[14]') [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 'power7_events_attr[15]') [-Werror]

Caused by commit 1c53a270724d ("perf/POWER7: Make generic event
translations available in sysfs").

I have used the tip tree from 20130128 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-20  4:54       ` Stephen Rothwell
@ 2012-08-20 15:09         ` Paul E. McKenney
  0 siblings, 0 replies; 357+ messages in thread
From: Paul E. McKenney @ 2012-08-20 15:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Mon, Aug 20, 2012 at 02:54:04PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Does the following help?
> 
> Yes, that fixes the warnings.  Please submit those two patches to the tip
> folks ASAP as I can't build the tip tree without them.

Will do.  Unless you tell me otherwise, with your Tested-by.

							Thanx, Paul

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-17 11:50     ` Paul E. McKenney
@ 2012-08-20  4:54       ` Stephen Rothwell
  2012-08-20 15:09         ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2012-08-20  4:54 UTC (permalink / raw)
  To: paulmck
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Hi Paul,

On Fri, 17 Aug 2012 04:50:19 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Does the following help?

Yes, that fixes the warnings.  Please submit those two patches to the tip
folks ASAP as I can't build the tip tree without them.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-17  0:56   ` Stephen Rothwell
@ 2012-08-17 11:50     ` Paul E. McKenney
  2012-08-20  4:54       ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2012-08-17 11:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Fri, Aug 17, 2012 at 10:56:33AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> > > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> > > 
> > > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> > > infrastructure").
> > > 
> > > I have used the tip tree from next-20120814 for today.
> > 
> > My first reaction was "we tested that!!!", but I see the conversion
> > from while(1) to do-while.  Does the following cure it?
> 
> Yes, that fixes the build problem.
> 
> However, the same commit is also responsible for all these new warnings:
> 
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task':
> drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park':
> drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task':
> drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void
> drivers/infiniband/hw/ehca/ehca_irq.c: At top level:
> drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type
> 
> Please address these.

Does the following help?

							Thanx, Paul

------------------------------------------------------------------------

infiniband: ehca: Fix compiler warnings

Fix comp_task() to return void to match smp_hotplug_thread's thread_fn
member, and adjust indirection on the ->cpu_comp_threads per-CPU
member of the ehca_comp_pool structure.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index 83a0095..8615d7c 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -707,7 +707,7 @@ static void queue_comp_task(struct ehca_cq *__cq)
 	BUG_ON(!cpu_online(cpu_id));
 
 	cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
-	thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
+	thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
 	BUG_ON(!cct || !thread);
 
 	spin_lock_irqsave(&cct->task_lock, flags);
@@ -716,7 +716,7 @@ static void queue_comp_task(struct ehca_cq *__cq)
 	if (cq_jobs > 0) {
 		cpu_id = find_next_online_cpu(pool);
 		cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
-		thread = per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
+		thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu_id);
 		BUG_ON(!cct || !thread);
 	}
 	__queue_comp_task(__cq, cct, thread);
@@ -761,7 +761,7 @@ static void comp_task_park(unsigned int cpu)
 
 	cpu = find_next_online_cpu(pool);
 	target = per_cpu_ptr(pool->cpu_comp_tasks, cpu);
-	thread = per_cpu_ptr(pool->cpu_comp_threads, cpu);
+	thread = *per_cpu_ptr(pool->cpu_comp_threads, cpu);
 	spin_lock_irq(&target->task_lock);
 	list_for_each_entry_safe(cq, tmp, &list, entry) {
 		list_del(&cq->entry);
@@ -788,7 +788,7 @@ static int comp_task_should_run(unsigned int cpu)
 	return cct->cq_jobs;
 }
 
-static int comp_task(unsigned int cpu)
+static void comp_task(unsigned int cpu)
 {
 	struct ehca_cpu_comp_task *cct = this_cpu_ptr(pool->cpu_comp_tasks);
 	int cql_empty;

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-16 19:46 ` Paul E. McKenney
@ 2012-08-17  0:56   ` Stephen Rothwell
  2012-08-17 11:50     ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2012-08-17  0:56 UTC (permalink / raw)
  To: paulmck
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi Paul,

On Thu, 16 Aug 2012 12:46:51 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> > drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> > 
> > Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> > infrastructure").
> > 
> > I have used the tip tree from next-20120814 for today.
> 
> My first reaction was "we tested that!!!", but I see the conversion
> from while(1) to do-while.  Does the following cure it?

Yes, that fixes the build problem.

However, the same commit is also responsible for all these new warnings:

drivers/infiniband/hw/ehca/ehca_irq.c: In function 'queue_comp_task':
drivers/infiniband/hw/ehca/ehca_irq.c:710:9: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c:719:10: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task_park':
drivers/infiniband/hw/ehca/ehca_irq.c:764:9: warning: assignment from incompatible pointer type
drivers/infiniband/hw/ehca/ehca_irq.c: In function 'comp_task':
drivers/infiniband/hw/ehca/ehca_irq.c:803:1: warning: no return statement in function returning non-void
drivers/infiniband/hw/ehca/ehca_irq.c: At top level:
drivers/infiniband/hw/ehca/ehca_irq.c:807:2: warning: initialization from incompatible pointer type

Please address these.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-08-16  3:12 Stephen Rothwell
@ 2012-08-16 19:46 ` Paul E. McKenney
  2012-08-17  0:56   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Paul E. McKenney @ 2012-08-16 19:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Rusty Russell, Namhyung Kim,
	Srivatsa S. Bhat

On Thu, Aug 16, 2012 at 01:12:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
> drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'
> 
> Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
> infrastructure").
> 
> I have used the tip tree from next-20120814 for today.

My first reaction was "we tested that!!!", but I see the conversion
from while(1) to do-while.  Does the following cure it?

							Thanx, Paul

------------------------------------------------------------------------

infiniband: ehca: Fix while->do-while conversion typo

This commit just adds a needed semicolon.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index 4eeac40..83a0095 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -668,7 +668,7 @@ static int find_next_online_cpu(struct ehca_comp_pool *pool)
 		if (cpu >= nr_cpu_ids)
 			cpu = cpumask_first(cpu_online_mask);
 		pool->last_cpu = cpu;
-	} while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active)
+	} while (!per_cpu_ptr(pool->cpu_comp_tasks, cpu)->active);
 	spin_unlock_irqrestore(&pool->last_cpu_lock, flags);
 
 	return cpu;

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-08-16  3:12 Stephen Rothwell
  2012-08-16 19:46 ` Paul E. McKenney
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2012-08-16  3:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Paul E. McKenney, Rusty Russell,
	Namhyung Kim, Srivatsa S. Bhat

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/infiniband/hw/ehca/ehca_irq.c: In function 'find_next_online_cpu':
drivers/infiniband/hw/ehca/ehca_irq.c:672:2: error: expected ';' before 'spin_unlock_irqrestore'

Caused by commit 81942621bd6b ("infiniband: Ehca: Use hotplug thread
infrastructure").

I have used the tip tree from next-20120814 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-21 12:19     ` Alan Cox
@ 2012-03-21 12:29       ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2012-03-21 12:29 UTC (permalink / raw)
  To: Alan Cox
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hi Alan,

On Wed, 21 Mar 2012 12:19:54 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> We don't even have a sep_driver.c any more. The massive rework of the SEP
> driver dealt with this.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
  2012-03-21  9:53     ` Alan Cox
@ 2012-03-21 12:19     ` Alan Cox
  2012-03-21 12:29       ` Stephen Rothwell
  2 siblings, 1 reply; 357+ messages in thread
From: Alan Cox @ 2012-03-21 12:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

We don't even have a sep_driver.c any more. The massive rework of the SEP
driver dealt with this.

Alan

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
@ 2012-03-21  9:53     ` Alan Cox
  2012-03-21 12:19     ` Alan Cox
  2 siblings, 0 replies; 357+ messages in thread
From: Alan Cox @ 2012-03-21  9:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Alan Cox,
	Andrew Morton

On Wed, 21 Mar 2012 09:00:38 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

I thought it was but apparently it got lost or I dropped the ball. I'll
sort it once git.kernel.org is back and I can pull a currentish -next
tree.

Alan

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-20 22:00   ` Stephen Rothwell
@ 2012-03-20 22:32     ` Greg KH
  2012-03-21  9:53     ` Alan Cox
  2012-03-21 12:19     ` Alan Cox
  2 siblings, 0 replies; 357+ messages in thread
From: Greg KH @ 2012-03-20 22:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

On Wed, Mar 21, 2012 at 09:00:38AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > > 
> > > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > > 
> > > Following previous instructions, I have disabled the staging tree driver
> > > using this patch (pending a fix in the tip tree):
> > 
> > Looks good to me.  Alan, care to send me an update that fixes this
> > driver for real?
> 
> Was this ever fixed?

I never got a patch from Alan or anyone else to do this :(

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-08 18:00 ` Greg KH
@ 2012-03-20 22:00   ` Stephen Rothwell
  2012-03-20 22:32     ` Greg KH
                       ` (2 more replies)
  0 siblings, 3 replies; 357+ messages in thread
From: Stephen Rothwell @ 2012-03-20 22:00 UTC (permalink / raw)
  To: Greg KH
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Hi all,

On Thu, 8 Mar 2012 10:00:48 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> > 
> > Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> > 
> > Following previous instructions, I have disabled the staging tree driver
> > using this patch (pending a fix in the tip tree):
> 
> Looks good to me.  Alan, care to send me an update that fixes this
> driver for real?

Was this ever fixed?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2012-03-08  4:21 Stephen Rothwell
@ 2012-03-08 18:00 ` Greg KH
  2012-03-20 22:00   ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Greg KH @ 2012-03-08 18:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Alan Cox, Andrew Morton

On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
> 
> Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
> 
> Following previous instructions, I have disabled the staging tree driver
> using this patch (pending a fix in the tip tree):

Looks good to me.  Alan, care to send me an update that fixes this
driver for real?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-03-08  4:21 Stephen Rothwell
  2012-03-08 18:00 ` Greg KH
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2012-03-08  4:21 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Greg KH, Alan Cox, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory

Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").

Following previous instructions, I have disabled the staging tree driver
using this patch (pending a fix in the tip tree):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Mar 2012 15:15:44 +1100
Subject: [PATCH] staging: disable the sep driver due to breakage

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/sep/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/sep/Kconfig b/drivers/staging/sep/Kconfig
index 92bf166..cd95ca2 100644
--- a/drivers/staging/sep/Kconfig
+++ b/drivers/staging/sep/Kconfig
@@ -1,6 +1,6 @@
 config DX_SEP
 	tristate "Discretix SEP driver"
-	depends on PCI
+	depends on PCI && BROKEN
 	help
 	  Discretix SEP driver; used for the security processor subsystem
 	  on bard the Intel Mobile Internet Device.
-- 
1.7.9.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-02-24  3:47 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2012-02-24  3:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David Howells

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/android/binder.c: In function 'task_get_unused_fd_flags':
drivers/staging/android/binder.c:383:39: error: request for member 'fds_bits' in something not a structure or union

Caused by commit 1fd36adcd98c ("Replace the fd_sets in struct fdtable
with an array of unsigned longs").

I have used the tip tree from next-20120223 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2012-02-24  3:34 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2012-02-24  3:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64_allmodconfig)
failed like this:

/opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy:arch/x86/vdso/vdso-note-x32.o: Invalid bfd target

I appears that we need a 2.22 binutils :-(

$ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --version
GNU objcopy (GNU Binutils) 2.21
$ /opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy --help
	.
	.
/opt/cross/gcc-4.6-nolibc/x86_64-linux/bin/x86_64-linux-objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 24 Feb 2012 14:27:17 +1100
Subject: [PATCH] x86: mark X86_X32_ABI broken for now until I get a better
 binutils

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 59c5b9c..e63a4dd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2159,7 +2159,7 @@ config IA32_AOUT
 
 config X86_X32_ABI
 	bool "x32 ABI for 64-bit mode (EXPERIMENTAL)"
-	depends on X86_64 && IA32_EMULATION && EXPERIMENTAL
+	depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN
 	---help---
 	  Include code to run binaries for the x32 native 32-bit ABI
 	  for 64-bit processors.  An x32 process gets access to the
-- 
1.7.9.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-06-27  4:22 Stephen Rothwell
@ 2011-06-28 10:55 ` Stijn Devriendt
  0 siblings, 0 replies; 357+ messages in thread
From: Stijn Devriendt @ 2011-06-28 10:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

I've already reported this to Thomas with a patch attached.

See https://lkml.org/lkml/2011/6/25/62

Regards,
Stijn

On Mon, Jun 27, 2011 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/i8253.c: In function 'setup_pit_timer':
> arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init'
> arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function)
>
> Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent").
> clockevent_i8253_init() doesn't appear to be declared in any header file
> even though it is introduced as a global function in commit 9f9119424bbc
> ("i8253: Create common clockevent implementation").  Similarly for
> i8253_clockevent.
>
> I have used the tip tree from next-20110624 for today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-06-27  4:22 Stephen Rothwell
  2011-06-28 10:55 ` Stijn Devriendt
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2011-06-27  4:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kernel/i8253.c: In function 'setup_pit_timer':
arch/x86/kernel/i8253.c:22:2: error: implicit declaration of function 'clockevent_i8253_init'
arch/x86/kernel/i8253.c:23:24: error: 'i8253_clockevent' undeclared (first use in this function)

Caused by commit 2739ce151665 ("x86: Use common i8253 clockevent").
clockevent_i8253_init() doesn't appear to be declared in any header file
even though it is introduced as a global function in commit 9f9119424bbc
("i8253: Create common clockevent implementation").  Similarly for
i8253_clockevent.

I have used the tip tree from next-20110624 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-04-01  2:00 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2011-04-01  2:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dirk Brandewie, Ben Dooks, Jean Delvare

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/i2c/busses/i2c-designware-core.c: In function 'i2c_dw_wait_bus_not_busy':
drivers/i2c/busses/i2c-designware-core.c:321: error: implicit declaration of function 'mdelay'

Caused by commit 800c56383dcb ("i2c-designware: split of i2c-designware.c
into core and bus specific parts") from the bjdooks-i2c tree and exposed
by commit ca444564a947 ("x86: Stop including <linux/delay.h> in two asm
header files").

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 Apr 2011 12:48:53 +1100
Subject: [PATCH] i2c-designware: mdelay use needs linux/delay.h inclusion

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/i2c/busses/i2c-designware-core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 299e717..f87e25a 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -25,6 +25,7 @@
  * ----------------------------------------------------------------------------
  *
  */
+#include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/errno.h>
 #include <linux/err.h>
-- 
1.7.4.1


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 22:47       ` Stephen Rothwell
@ 2011-02-18  3:54         ` Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2011-02-18  3:54 UTC (permalink / raw)
  To: Michal Marek
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hi Michal,

On Fri, 18 Feb 2011 09:47:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
> >
> > > _Maybe_ we could work around it by letting fixdep remove the actual
> > > source file from the list of dependencies in the .cmd file. The
> > > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > > .cmd file is only needed for additional dependencies on headers. Let's
> > > see what else breaks then ;).
> > 
> > It seems to work for me. Can you try the patch below? It needs to be
> > applied before merging 9599ec0 to have any effect.
> 
> Thanks, I will apply this as a fix on top of Linus' tree before I merge
> anything else.  It looks simple enough that Linus may take it as a fix
> right now.   Better to convince ourselves first, though, right?

That patch fixed the problem for me and has caused no obvious problems.

Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 15:02     ` Michal Marek
  2011-02-17 17:11       ` Ingo Molnar
@ 2011-02-17 22:47       ` Stephen Rothwell
  2011-02-18  3:54         ` Stephen Rothwell
  1 sibling, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2011-02-17 22:47 UTC (permalink / raw)
  To: Michal Marek
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Hi Michal,

On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> > _Maybe_ we could work around it by letting fixdep remove the actual
> > source file from the list of dependencies in the .cmd file. The
> > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > .cmd file is only needed for additional dependencies on headers. Let's
> > see what else breaks then ;).
> 
> It seems to work for me. Can you try the patch below? It needs to be
> applied before merging 9599ec0 to have any effect.

Thanks, I will apply this as a fix on top of Linus' tree before I merge
anything else.  It looks simple enough that Linus may take it as a fix
right now.   Better to convince ourselves first, though, right?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 15:02     ` Michal Marek
@ 2011-02-17 17:11       ` Ingo Molnar
  2011-02-17 22:47       ` Stephen Rothwell
  1 sibling, 0 replies; 357+ messages in thread
From: Ingo Molnar @ 2011-02-17 17:11 UTC (permalink / raw)
  To: Michal Marek
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Fenghua Yu


* Michal Marek <mmarek@suse.cz> wrote:

> @@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
>  		if (strrcmp(s, "include/generated/autoconf.h") &&
>  		    strrcmp(s, "arch/um/include/uml-config.h") &&
>  		    strrcmp(s, ".ver")) {
> -			printf("  %s \\\n", s);
> +			/* Do not output the first dependency (the
> +			 * source file), so that kbuild is not confused
> +			 * if a .c file is rewritten into .S or vice
> +			 * versa.
> +			 */

Just a really minor nitpick, please use the standard comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17 13:18   ` Michal Marek
@ 2011-02-17 15:02     ` Michal Marek
  2011-02-17 17:11       ` Ingo Molnar
  2011-02-17 22:47       ` Stephen Rothwell
  0 siblings, 2 replies; 357+ messages in thread
From: Michal Marek @ 2011-02-17 15:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

On Thu, Feb 17, 2011 at 02:18:18PM +0100, Michal Marek wrote:
> On 17.2.2011 04:47, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> failed like this:
> >>
> >> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> >>
> >> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> >> Convert memmove() to assembly file and fix return value bug") interacting
> >> with our build system.
> >>
> >> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> >> before merging the tip tree) from my object tree, it built correctly.
> > 
> > I am still getting this (of course).
> > 
> > Michal, is there anything that the kbuild system can do for us here?
> > Basically we have changed from using a .c file to generate a .o to using
> > a .S but the build system does not regenerate the .cmd file.
> 
> _Maybe_ we could work around it by letting fixdep remove the actual
> source file from the list of dependencies in the .cmd file. The
> dependency on the .c / .S / whatever file is given by the Makefiles, the
> .cmd file is only needed for additional dependencies on headers. Let's
> see what else breaks then ;).

It seems to work for me. Can you try the patch below? It needs to be
applied before merging 9599ec0 to have any effect.

Michal

From: Michal Marek <mmarek@suse.cz>
Subject: [PATCH] fixdep: Do not record dependency on the source file itself

The dependency is already expressed by the Makefiles, storing it in the
.cmd file breaks build if a .c file is replaced by .S or vice versa,
because the .cmd file contains

foo/bar.o: foo/bar.c ...

foo/bar.c ... :

so the foo/bar.c -> foo/bar.o rule triggers even if there is no
foo/bar.c anymore.

Signed-off-by: Michal Marek <mmarek@suse.cz>

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index c9a16ab..9264725 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -315,6 +315,7 @@ static void parse_dep_file(void *map, size_t len)
 	char *end = m + len;
 	char *p;
 	char s[PATH_MAX];
+	int first;
 
 	p = strchr(m, ':');
 	if (!p) {
@@ -327,6 +328,7 @@ static void parse_dep_file(void *map, size_t len)
 
 	clear_config();
 
+	first = 1;
 	while (m < end) {
 		while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
 			m++;
@@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
 		if (strrcmp(s, "include/generated/autoconf.h") &&
 		    strrcmp(s, "arch/um/include/uml-config.h") &&
 		    strrcmp(s, ".ver")) {
-			printf("  %s \\\n", s);
+			/* Do not output the first dependency (the
+			 * source file), so that kbuild is not confused
+			 * if a .c file is rewritten into .S or vice
+			 * versa.
+			 */
+			if (!first)
+				printf("  %s \\\n", s);
 			do_config_file(s);
 		}
+		first = 0;
 		m = p + 1;
 	}
 	printf("\n%s: $(deps_%s)\n\n", target, target);

^ permalink raw reply related	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-02-17  3:47 ` Stephen Rothwell
@ 2011-02-17 13:18   ` Michal Marek
  2011-02-17 15:02     ` Michal Marek
  0 siblings, 1 reply; 357+ messages in thread
From: Michal Marek @ 2011-02-17 13:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Fenghua Yu

On 17.2.2011 04:47, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
>>
>> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
>> Convert memmove() to assembly file and fix return value bug") interacting
>> with our build system.
>>
>> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
>> before merging the tip tree) from my object tree, it built correctly.
> 
> I am still getting this (of course).
> 
> Michal, is there anything that the kbuild system can do for us here?
> Basically we have changed from using a .c file to generate a .o to using
> a .S but the build system does not regenerate the .cmd file.

_Maybe_ we could work around it by letting fixdep remove the actual
source file from the list of dependencies in the .cmd file. The
dependency on the .c / .S / whatever file is given by the Makefiles, the
.cmd file is only needed for additional dependencies on headers. Let's
see what else breaks then ;).

Michal

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2011-01-31  4:42 Stephen Rothwell
@ 2011-02-17  3:47 ` Stephen Rothwell
  2011-02-17 13:18   ` Michal Marek
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2011-02-17  3:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu, Michal Marek

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

Hi all,

On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> 
> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> Convert memmove() to assembly file and fix return value bug") interacting
> with our build system.
> 
> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> before merging the tip tree) from my object tree, it built correctly.

I am still getting this (of course).

Michal, is there anything that the kbuild system can do for us here?
Basically we have changed from using a .c file to generate a .o to using
a .S but the build system does not regenerate the .cmd file.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2011-01-31  4:42 Stephen Rothwell
  2011-02-17  3:47 ` Stephen Rothwell
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2011-01-31  4:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu, Michal Marek

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory

Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
Convert memmove() to assembly file and fix return value bug") interacting
with our build system.

After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
before merging the tip tree) from my object tree, it built correctly.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-10-19  5:13 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2010-10-19  5:13 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/bin/sh: /scratch/sfr/x86_64_allmodconfig/scripts/recordmcount: No such file or directory

I use O=/scratch/sfr/x86_64_allmodconfig in this build.  The same
happened yesterday, but it fixed itself when I rebuilt for other
reasons.  Andrew has also reported this so I applied the patch you
suggested.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-07-29  3:04 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2010-07-29  3:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jason Wessel, John Stultz

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

kernel/debug/kdb/kdb_main.c: In function 'kdb_summary':
kernel/debug/kdb/kdb_main.c:2457: error: 'xtime' undeclared (first use in this function)

Caused by commit 0fb86b06298b6cd3205cac2e68a499f269282dac ("imekeeping:
Make xtime and wall_to_monotonic static") from the tip tree interacting
with commit 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb
back end (1 of 2)") which was merged before v2.6.35-rc1.

I have used the tip tree from next-20100727 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2010-05-10  4:49 Stephen Rothwell
@ 2010-05-10  5:09 ` H. Peter Anvin
  0 siblings, 0 replies; 357+ messages in thread
From: H. Peter Anvin @ 2010-05-10  5:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel

On 05/09/2010 09:49 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory
> drivers/misc/vmware_balloon.c: In function 'vmballoon_init':
> drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform'
> 
> Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up
> the hypervisor layer").  (Yes, I know this has already been reported.)
> 
> I have used the version of the tip tree from next-20100507 for today.

Working on it.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-05-10  4:49 Stephen Rothwell
  2010-05-10  5:09 ` H. Peter Anvin
  0 siblings, 1 reply; 357+ messages in thread
From: Stephen Rothwell @ 2010-05-10  4:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/misc/vmware_balloon.c:44:24: error: asm/vmware.h: No such file or directory
drivers/misc/vmware_balloon.c: In function 'vmballoon_init':
drivers/misc/vmware_balloon.c:770: error: implicit declaration of function 'vmware_platform'

Caused by commit e08cae4181af9483b04ecfac48f01c8e5a5f27bf ("x86: Clean up
the hypervisor layer").  (Yes, I know this has already been reported.)

I have used the version of the tip tree from next-20100507 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

* linux-next: build failure after merge of the tip tree
@ 2010-03-12  4:00 Stephen Rothwell
  0 siblings, 0 replies; 357+ messages in thread
From: Stephen Rothwell @ 2010-03-12  4:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Frederic Weisbecker

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".perf_arch_fetch_caller_regs" [fs/xfs/xfs.ko] undefined!
ERROR: ".perf_arch_fetch_caller_regs" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!

Caused by commit 5331d7b84613b8325362dde53dc2bff2fb87d351 ("perf:
Introduce new perf_fetch_caller_regs() for hot regs snapshot") from the
tip tree.  Presumably commit 639fe4b12f92b54c9c3b38c82cdafaa38cfd3e63
("perf: export perf_trace_regs and perf_arch_fetch_caller_regs") should
have exported the weak version as well as the x86 one.

I have used the version of the tip tree from next-20100311 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 357+ messages in thread

end of thread, other threads:[~2024-01-29  8:14 UTC | newest]

Thread overview: 357+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-05  6:25 linux-next: build failure after merge of the tip tree Stephen Rothwell
2011-10-05  8:46 ` Peter Zijlstra
2011-10-11  6:15   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-01-29  1:22 Stephen Rothwell
2024-01-29  8:14 ` Bartosz Golaszewski
2023-08-15  5:29 Stephen Rothwell
2023-08-15 15:54 ` Edgecombe, Rick P
2023-06-20  4:53 Stephen Rothwell
2023-04-21 16:03 broonie
2023-04-19 18:21 linux-next: Build " broonie
2023-04-19 18:50 ` Borislav Petkov
2022-12-13  1:40 linux-next: build " Stephen Rothwell
2022-12-15 16:34 ` Ricardo Neri
2022-12-05  1:15 Stephen Rothwell
2022-12-02  0:26 Stephen Rothwell
2022-12-02  1:33 ` Benjamin Gray
2022-12-02  9:37 ` Michael Ellerman
2022-03-15  3:06 Stephen Rothwell
2022-03-15  5:23 ` Stephen Rothwell
2022-03-15  5:37   ` Stephen Rothwell
2022-03-15  8:42     ` Stephen Rothwell
2022-03-15  9:22     ` Peter Zijlstra
2022-03-15 10:41       ` Stephen Rothwell
2021-12-13 17:08 broonie
2021-11-26  3:52 Stephen Rothwell
2021-11-26 10:01 ` Arnd Bergmann
2021-12-01 22:05   ` Stephen Rothwell
2021-12-01 22:17     ` Thomas Gleixner
2021-12-01 22:19       ` Thomas Gleixner
2021-12-01 22:31         ` Stephen Rothwell
2021-10-25  4:11 Stephen Rothwell
2021-10-25  7:42 ` Borislav Petkov
2021-10-25  7:58   ` Stephen Rothwell
2021-10-25  8:37     ` Borislav Petkov
2021-10-28  5:10 ` Stephen Rothwell
2021-10-28  8:17   ` Borislav Petkov
2021-10-18  6:23 Stephen Rothwell
2021-10-18  6:45 ` Qi Zheng
2021-10-06  2:58 Stephen Rothwell
2021-10-06  9:31 ` Borislav Petkov
2021-10-06  9:54   ` Stephen Rothwell
2021-10-06  9:56     ` Borislav Petkov
2021-06-28  3:36 Stephen Rothwell
2021-06-28  5:42 ` Ingo Molnar
2021-05-13  2:05 Stephen Rothwell
2021-05-13 10:51 ` Ingo Molnar
2021-05-13 11:11   ` H. Peter Anvin
2021-03-22  3:37 Stephen Rothwell
2021-03-22  9:00 ` Borislav Petkov
2021-03-26  8:57   ` Sedat Dilek
2021-03-26 13:11     ` Borislav Petkov
2021-03-27 11:50       ` Sedat Dilek
2021-03-27 21:26         ` Stephen Rothwell
2021-03-23  8:34 ` Sedat Dilek
2021-03-17  4:08 Stephen Rothwell
2021-03-17 10:54 ` Borislav Petkov
2021-03-17 16:22   ` Ian Rogers
2021-03-17 18:02     ` Borislav Petkov
2021-03-17 18:49       ` Stephen Rothwell
2021-03-17 19:18         ` Borislav Petkov
2021-03-17 20:04           ` Ingo Molnar
2021-03-17 21:54             ` Stephen Rothwell
2021-03-02 23:38 Stephen Rothwell
2021-03-03  9:44 ` Peter Zijlstra
2021-03-03 11:29   ` Stephen Rothwell
2021-01-14  4:11 Stephen Rothwell
2021-01-14 10:07 ` Borislav Petkov
2020-11-27  4:10 Stephen Rothwell
2020-11-27 10:11 ` Ingo Molnar
2020-11-09  3:34 Stephen Rothwell
2020-10-09  4:28 Stephen Rothwell
2020-10-09  6:47 ` Vasily Gorbik
2020-09-08  9:12 Stephen Rothwell
2020-09-08 10:57 ` peterz
2020-09-03  2:35 Stephen Rothwell
2020-09-03  3:51 ` Ingo Molnar
2020-09-03  4:44   ` Stephen Rothwell
2020-08-03  5:45 Stephen Rothwell
2020-07-31  5:53 Stephen Rothwell
2020-07-31  9:57 ` Ingo Molnar
2020-07-31 10:02   ` Stephen Rothwell
2020-06-22  1:37 Stephen Rothwell
2020-06-30  2:54 ` Stephen Rothwell
2020-07-07  2:33   ` Stephen Rothwell
2020-07-14  3:50     ` Stephen Rothwell
2020-07-20  5:37       ` Stephen Rothwell
2020-06-21  6:33 Stephen Rothwell
2020-06-21 10:53 ` Borislav Petkov
2020-06-22  1:38   ` Stephen Rothwell
2020-05-21 17:31 Stephen Rothwell
2020-05-21 17:35 ` Will Deacon
2020-05-22  7:17   ` Stephen Rothwell
2020-05-22  7:49     ` Stephen Rothwell
2020-05-23  0:12       ` Paul E. McKenney
2020-05-23  6:46         ` Borislav Petkov
2020-05-23  9:54           ` Thomas Gleixner
2020-05-23 15:06             ` Paul E. McKenney
2020-05-23 19:05               ` Thomas Gleixner
2020-05-23 21:23                 ` Paul E. McKenney
2020-05-25  0:37                   ` Paul E. McKenney
2020-05-25  8:20                     ` Marco Elver
2020-05-25 16:13                       ` Paul E. McKenney
2020-05-15  6:00 Stephen Rothwell
2020-03-30  3:35 Stephen Rothwell
2020-03-30  3:53 ` H.J. Lu
2020-03-30  4:08   ` Stephen Rothwell
2020-03-30  7:48     ` Borislav Petkov
2020-03-30  8:04       ` Michael Ellerman
2020-03-30  8:16         ` Borislav Petkov
2020-03-30 11:34           ` H.J. Lu
2020-03-26  2:52 Stephen Rothwell
2020-03-26 10:59 ` Qais Yousef
2020-04-01  1:14 ` Stephen Rothwell
2020-04-03  8:15   ` Baolin Wang
2020-04-03  9:50     ` Sebastian Reichel
2019-11-21  3:54 Stephen Rothwell
2019-11-21  8:36 ` Peter Zijlstra
2019-11-21 18:37 ` Alex Deucher
2019-11-18  3:11 Stephen Rothwell
2019-11-18  9:49 ` Jiri Slaby
2019-11-18 12:49 ` Borislav Petkov
2019-10-21  2:13 Stephen Rothwell
2019-10-21  5:51 ` Ingo Molnar
2019-10-21  6:37   ` Stephen Rothwell
2019-10-10  2:14 Stephen Rothwell
2019-10-10  8:02 ` Ingo Molnar
2019-10-10 11:23   ` Stephen Rothwell
2019-10-10 13:44     ` Daniel Vetter
2019-11-06  2:53 ` Stephen Rothwell
2019-11-27 23:39   ` Stephen Rothwell
2019-08-29  6:20 Stephen Rothwell
2019-08-29  7:46 ` Peter Zijlstra
2019-08-29 12:24   ` Thomas Gleixner
2019-08-29 13:04     ` Peter Zijlstra
2019-08-08  4:48 Stephen Rothwell
2019-08-01  3:38 Stephen Rothwell
2019-07-09  6:54 Stephen Rothwell
2019-07-10  0:01 ` Stephen Rothwell
2019-07-10 18:21   ` Ilya Dryomov
2019-07-10 21:38     ` Stephen Rothwell
2019-07-02  5:33 Stephen Rothwell
2019-07-02 10:28 ` David Sterba
2019-07-02 12:57   ` Stephen Rothwell
2019-07-08  6:50   ` Stephen Rothwell
2019-06-25  6:04 Stephen Rothwell
2019-06-25  6:23 ` Kalle Valo
2019-06-25  6:26   ` Thomas Gleixner
2019-06-25  6:36   ` Stephen Rothwell
2019-06-25  6:51     ` Kalle Valo
2019-06-25  6:56     ` Thomas Gleixner
2019-06-25  7:47       ` Kalle Valo
2019-07-09  0:09 ` Stephen Rothwell
2019-07-09  3:46 ` Stephen Rothwell
2018-11-06  0:43 Stephen Rothwell
2018-08-08 23:24 Stephen Rothwell
2018-08-09  9:41 ` Joerg Roedel
2018-04-03  5:41 Stephen Rothwell
2018-04-03  9:30 ` Peter Zijlstra
2018-04-03 12:39 ` David Howells
2018-04-03 12:42   ` Peter Zijlstra
2018-04-03 12:41 ` David Howells
2017-11-08  2:47 Stephen Rothwell
2017-11-08  3:01 ` Josh Poimboeuf
2017-11-08  7:35   ` Stephen Rothwell
2017-11-08  9:18   ` Ingo Molnar
2017-11-08 12:14     ` Stephen Rothwell
2017-11-09  6:18       ` Ingo Molnar
2017-11-08 13:17     ` Josh Poimboeuf
2017-11-09  3:03     ` Stephen Rothwell
2017-11-01 10:51 Stephen Rothwell
2017-11-01 14:32 ` Kees Cook
2017-06-28  3:43 Stephen Rothwell
2017-06-28  4:00 ` jeffy
2017-06-28  4:24   ` Stephen Rothwell
2017-07-03  3:01 ` Stephen Rothwell
2017-05-02  3:17 Stephen Rothwell
2017-04-24  3:32 Stephen Rothwell
2017-04-24  5:31 ` Ingo Molnar
2017-04-05  3:36 Stephen Rothwell
2017-04-05  7:24 ` Mikko Perttunen
2016-12-07  1:37 Stephen Rothwell
2016-12-07  7:45 ` Ingo Molnar
2016-12-07  8:12   ` Jiri Olsa
2016-12-07 14:49     ` Arnaldo Carvalho de Melo
2016-12-07 18:56       ` Ingo Molnar
2016-12-07 20:32         ` Stephen Rothwell
2016-11-17  3:22 Stephen Rothwell
2016-09-29  3:20 Stephen Rothwell
2016-09-29 12:25 ` Rafael J. Wysocki
2016-09-29 15:54   ` Chen, Yu C
2016-09-29 20:50     ` Rafael J. Wysocki
2016-09-21  3:23 Stephen Rothwell
2016-09-21  6:44 ` Viresh Kumar
2016-07-18  8:29 Stephen Rothwell
2016-07-18 14:27 ` Paul Gortmaker
2016-07-18  5:15 Stephen Rothwell
2016-04-18  3:03 Stephen Rothwell
2016-04-14  2:14 Stephen Rothwell
2016-04-14 12:35 ` Arnaldo Carvalho de Melo
2016-04-14 12:55   ` Michael Ellerman
2016-04-14 15:08     ` Arnaldo Carvalho de Melo
2016-04-15 21:15 ` Arnaldo Carvalho de Melo
2016-04-15 21:28   ` Arnaldo Carvalho de Melo
2016-04-17 12:12     ` Jiri Olsa
2016-04-17 13:04       ` Jiri Olsa
2016-04-18 13:24         ` Arnaldo Carvalho de Melo
2016-04-18 13:28           ` Jiri Olsa
2016-03-01  1:29 Stephen Rothwell
2016-03-01  7:07 ` Ingo Molnar
2016-03-01  7:28   ` Sedat Dilek
2016-03-01  7:39     ` H. Peter Anvin
2016-03-01  8:41       ` Sedat Dilek
2016-03-01  9:45       ` Ingo Molnar
2016-03-01  9:40   ` Stephen Rothwell
2015-09-16  1:30 Stephen Rothwell
2015-09-16  4:53 ` David Miller
2015-09-16  0:12 Stephen Rothwell
2015-09-16  6:16 ` Jiri Olsa
2015-09-16  6:38   ` Jiri Olsa
2015-09-16  7:30     ` Stephen Rothwell
2015-09-16 14:17       ` Arnaldo Carvalho de Melo
2015-09-17  0:34   ` Stephen Rothwell
2015-09-30  2:56     ` Stephen Rothwell
2015-09-30  6:08       ` Jiri Olsa
2015-09-30  6:17         ` Stephen Rothwell
2015-07-28  5:33 Stephen Rothwell
2015-07-28 16:34 ` Luis R. Rodriguez
2015-07-28 18:17   ` Luis R. Rodriguez
2015-07-28  2:43 Stephen Rothwell
2015-07-28  8:41 ` Sudeep Holla
2015-07-28  9:43   ` Gregory CLEMENT
2015-07-15  1:01 Stephen Rothwell
2015-07-08  0:56 Stephen Rothwell
2015-07-08  9:40 ` Thomas Gleixner
2015-06-12 10:51 Michael Ellerman
     [not found] ` <BY1PR0701MB17063C25D627AF725A9E0D46FEBB0@BY1PR0701MB1706.namprd07.prod.outlook.com>
2015-06-12 21:22   ` David Miller
2015-06-12 21:25     ` Chickles, Derek
2015-06-09  7:15 Stephen Rothwell
2015-04-07  7:18 Stephen Rothwell
2015-04-07  8:48 ` Ingo Molnar
2015-04-07  8:56   ` Daniel Borkmann
2015-04-07  9:05     ` Stephen Rothwell
2015-04-07 11:13       ` Daniel Borkmann
2015-04-07 16:18         ` Alexei Starovoitov
2015-04-07 19:54           ` Daniel Borkmann
2015-04-08  5:03             ` Stephen Rothwell
2015-04-15  1:25               ` Stephen Rothwell
2015-04-07  8:53 ` Peter Zijlstra
2015-03-30  6:13 Stephen Rothwell
2015-03-30  7:15 ` Russell King - ARM Linux
2015-03-30  8:08   ` Stephen Rothwell
2015-03-30 14:57     ` Nathan Lynch
2015-03-30 15:08       ` Russell King - ARM Linux
2015-03-30 15:24         ` Nathan Lynch
2015-04-13 23:34         ` Stephen Rothwell
2014-07-25  4:45 Stephen Rothwell
2014-07-29 23:56 ` Stephen Rothwell
2014-07-30  3:10   ` John Stultz
2014-06-04  6:05 Stephen Rothwell
2014-06-04 10:49 ` Thomas Gleixner
2014-06-04 14:46   ` Linus Torvalds
2014-06-04 16:23   ` Olof Johansson
2014-06-04 20:02     ` Thomas Gleixner
2014-05-23  7:14 Stephen Rothwell
2014-05-29  1:38 ` Stephen Rothwell
2014-04-24  3:51 Stephen Rothwell
2014-02-12  2:41 Stephen Rothwell
2014-02-12  4:48 ` Preeti U Murthy
2014-02-11  3:00 Stephen Rothwell
2014-01-16  3:58 Stephen Rothwell
2014-01-16 12:19 ` Peter Zijlstra
2014-01-16 20:46   ` Stephen Rothwell
2014-01-16 22:25     ` Peter Zijlstra
2014-01-16 22:34       ` Stephen Rothwell
2014-01-16 22:51         ` H. Peter Anvin
2014-01-17  3:45           ` Stephen Rothwell
2014-01-18  9:46             ` Mike Galbraith
2014-01-18 12:44               ` Peter Zijlstra
2014-01-18 14:06                 ` Sabrina Dubroca
2014-01-18 15:21                 ` Mike Galbraith
2014-01-18 19:14                   ` H. Peter Anvin
2014-01-18 21:54                     ` Peter Zijlstra
2014-01-20  3:51               ` Stephen Rothwell
2014-01-20  8:42                 ` Sedat Dilek
2014-01-20  8:46                   ` Sedat Dilek
2014-01-20 13:10                     ` Stephen Rothwell
2014-01-20 15:28                       ` Sedat Dilek
2014-01-20  9:17                   ` Mike Galbraith
2014-01-20  9:25                     ` Sedat Dilek
2014-01-20  9:48                       ` Mike Galbraith
2014-01-20  4:45     ` Len Brown
2014-01-20  8:26       ` Peter Zijlstra
2014-01-20  8:56         ` H. Peter Anvin
2014-01-20  9:16           ` Peter Zijlstra
2014-01-20  9:23             ` H. Peter Anvin
2014-01-20  9:29               ` Ingo Molnar
2014-01-20 21:39                 ` Len Brown
2014-01-20 21:51                   ` Peter Zijlstra
2014-01-21  3:26                     ` Mike Galbraith
2014-01-21 10:47                     ` Ingo Molnar
2014-01-20  9:55               ` Peter Zijlstra
2014-01-20 11:00                 ` H. Peter Anvin
2014-01-20 11:05                   ` Peter Zijlstra
2014-01-16 20:56   ` H. Peter Anvin
2014-01-20  1:00 ` Len Brown
2014-01-20  1:07   ` H. Peter Anvin
2014-01-20  8:30   ` Peter Zijlstra
2014-01-20 10:13     ` Peter Zijlstra
2014-01-20 10:19       ` H. Peter Anvin
2014-01-20 11:06         ` Peter Zijlstra
2014-01-14  3:26 Stephen Rothwell
2014-01-14 14:14 ` Peter Zijlstra
2014-01-14 19:06   ` Mikulas Patocka
2014-01-14 20:05     ` Peter Zijlstra
2014-01-14 21:43       ` Mikulas Patocka
2014-01-14 22:03         ` Rafael J. Wysocki
2014-01-14 21:52           ` Mikulas Patocka
2014-01-14 22:18             ` Rafael J. Wysocki
2014-01-16 12:14         ` Peter Zijlstra
2013-10-28  9:24 Stephen Rothwell
2013-10-28 10:18 ` Thierry Reding
2013-10-28 10:26   ` Ingo Molnar
2013-10-29  6:00     ` Stephen Rothwell
2013-04-29  5:45 Stephen Rothwell
2013-02-14  2:30 Stephen Rothwell
2013-02-21  2:04 ` Stephen Rothwell
2013-02-02  5:04 Stephen Rothwell
2012-08-16  3:12 Stephen Rothwell
2012-08-16 19:46 ` Paul E. McKenney
2012-08-17  0:56   ` Stephen Rothwell
2012-08-17 11:50     ` Paul E. McKenney
2012-08-20  4:54       ` Stephen Rothwell
2012-08-20 15:09         ` Paul E. McKenney
2012-03-08  4:21 Stephen Rothwell
2012-03-08 18:00 ` Greg KH
2012-03-20 22:00   ` Stephen Rothwell
2012-03-20 22:32     ` Greg KH
2012-03-21  9:53     ` Alan Cox
2012-03-21 12:19     ` Alan Cox
2012-03-21 12:29       ` Stephen Rothwell
2012-02-24  3:47 Stephen Rothwell
2012-02-24  3:34 Stephen Rothwell
2011-06-27  4:22 Stephen Rothwell
2011-06-28 10:55 ` Stijn Devriendt
2011-04-01  2:00 Stephen Rothwell
2011-01-31  4:42 Stephen Rothwell
2011-02-17  3:47 ` Stephen Rothwell
2011-02-17 13:18   ` Michal Marek
2011-02-17 15:02     ` Michal Marek
2011-02-17 17:11       ` Ingo Molnar
2011-02-17 22:47       ` Stephen Rothwell
2011-02-18  3:54         ` Stephen Rothwell
2010-10-19  5:13 Stephen Rothwell
2010-07-29  3:04 Stephen Rothwell
2010-05-10  4:49 Stephen Rothwell
2010-05-10  5:09 ` H. Peter Anvin
2010-03-12  4:00 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).