Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the rcu tree
@ 2019-08-12  6:12 Stephen Rothwell
  2019-08-12 16:19 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2019-08-12  6:12 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

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

Hi all,

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

arch/x86/xen/smp_pv.c: In function 'xen_pv_play_dead':
arch/x86/xen/smp_pv.c:439:2: error: implicit declaration of function 'tick_nohz_idle_stop_tick_protected'; did you mean 'tick_nohz_idle_stop_tick'? [-Werror=implicit-function-declaration]
  tick_nohz_idle_stop_tick_protected();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  tick_nohz_idle_stop_tick

Caused by commit

  a96f9dca9820 ("idle: Prevent late-arriving interrupts from disrupting offline")

Also:

In file included from <command-line>:
include/linux/rcu_segcblist.h:69:2: error: unknown type name 'atomic_long_t'
  atomic_long_t len;
  ^~~~~~~~~~~~~
include/linux/rcu_segcblist.h:74:2: error: unknown type name 'u8'
  u8 enabled;
  ^~
include/linux/rcu_segcblist.h:75:2: error: unknown type name 'u8'
  u8 offloaded;
  ^~

Caused by commits:

  e084617762b7 ("rcu/nocb: Use separate flag to indicate disabled ->cblist")
  5e114ba3d7a5 ("rcu/nocb: Use separate flag to indicate offloaded ->cblist")
  9f3ca0945104 ("rcu/nocb: Atomic ->len field in rcu_segcblist structure")

We prefer our include files to be standalone now if at all possible.

I have used the rcu tree from next-20190809 for today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-08-12  6:12 linux-next: build failure after merge of the rcu tree Stephen Rothwell
@ 2019-08-12 16:19 ` Paul E. McKenney
  2019-08-13  5:25   ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2019-08-12 16:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

On Mon, Aug 12, 2019 at 04:12:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/xen/smp_pv.c: In function 'xen_pv_play_dead':
> arch/x86/xen/smp_pv.c:439:2: error: implicit declaration of function 'tick_nohz_idle_stop_tick_protected'; did you mean 'tick_nohz_idle_stop_tick'? [-Werror=implicit-function-declaration]
>   tick_nohz_idle_stop_tick_protected();
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   tick_nohz_idle_stop_tick
> 
> Caused by commit
> 
>   a96f9dca9820 ("idle: Prevent late-arriving interrupts from disrupting offline")

Peter, I reverted the portion of this commit that removes the
tick_nohz_idle_stop_tick_protected() function.  Please let me know if
you instead convince the Xen people to stop using it.

> Also:
> 
> In file included from <command-line>:
> include/linux/rcu_segcblist.h:69:2: error: unknown type name 'atomic_long_t'
>   atomic_long_t len;
>   ^~~~~~~~~~~~~
> include/linux/rcu_segcblist.h:74:2: error: unknown type name 'u8'
>   u8 enabled;
>   ^~
> include/linux/rcu_segcblist.h:75:2: error: unknown type name 'u8'
>   u8 offloaded;
>   ^~
> 
> Caused by commits:
> 
>   e084617762b7 ("rcu/nocb: Use separate flag to indicate disabled ->cblist")
>   5e114ba3d7a5 ("rcu/nocb: Use separate flag to indicate offloaded ->cblist")
>   9f3ca0945104 ("rcu/nocb: Atomic ->len field in rcu_segcblist structure")
> 
> We prefer our include files to be standalone now if at all possible.

Huh.  "It has been building fine for me."  I added

	#include <uapi/asm-generic/types.h>
	#include <asm-generic/atomic-long.h>

to include/linux/rcu_segcblist.h, which hopefully fixes it at your end.
I will push this after testing and rearrangement at this end.

							Thanx, Paul

> I have used the rcu tree from next-20190809 for today.
> 
> -- 
> Cheers,
> Stephen Rothwell



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

* Re: linux-next: build failure after merge of the rcu tree
  2019-08-12 16:19 ` Paul E. McKenney
@ 2019-08-13  5:25   ` Stephen Rothwell
  2019-08-13 14:38     ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2019-08-13  5:25 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

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

Hi Paul,

On Mon, 12 Aug 2019 09:19:34 -0700 "Paul E. McKenney" <paulmck@linux.ibm.com> wrote:
>
> Huh.  "It has been building fine for me."  I added
> 
> 	#include <uapi/asm-generic/types.h>
> 	#include <asm-generic/atomic-long.h>
> 
> to include/linux/rcu_segcblist.h, which hopefully fixes it at your end.

That did not work as I got a lot of errors from
include/asm-generic/atomic-long.h.  I have added the following patch
for today (which does build).  These errors come from having
CONFIG_{,KERNEL_,UAPI_}HEADER_TEST set (which allmodconfig a should do).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Aug 2019 15:12:00 +1000
Subject: [PATCH] rcu: use the correct includes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/rcu_segcblist.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
index 43e2935e8966..646759042333 100644
--- a/include/linux/rcu_segcblist.h
+++ b/include/linux/rcu_segcblist.h
@@ -14,8 +14,8 @@
 #ifndef __INCLUDE_LINUX_RCU_SEGCBLIST_H
 #define __INCLUDE_LINUX_RCU_SEGCBLIST_H
 
-#include <uapi/asm-generic/types.h>
-#include <asm-generic/atomic-long.h>
+#include <linux/types.h>
+#include <linux/atomic.h>
 
 /* Simple unsegmented callback lists. */
 struct rcu_cblist {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-08-13  5:25   ` Stephen Rothwell
@ 2019-08-13 14:38     ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2019-08-13 14:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

On Tue, Aug 13, 2019 at 03:25:11PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 12 Aug 2019 09:19:34 -0700 "Paul E. McKenney" <paulmck@linux.ibm.com> wrote:
> >
> > Huh.  "It has been building fine for me."  I added
> > 
> > 	#include <uapi/asm-generic/types.h>
> > 	#include <asm-generic/atomic-long.h>
> > 
> > to include/linux/rcu_segcblist.h, which hopefully fixes it at your end.
> 
> That did not work as I got a lot of errors from
> include/asm-generic/atomic-long.h.  I have added the following patch
> for today (which does build).  These errors come from having
> CONFIG_{,KERNEL_,UAPI_}HEADER_TEST set (which allmodconfig a should do).
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 13 Aug 2019 15:12:00 +1000
> Subject: [PATCH] rcu: use the correct includes
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thank you, Stephen, I have merged this in with attribution.  Apologies
for my not being with the times on this one, and "make allmodconfig" it
will be in the future!

							Thanx, Paul

> ---
>  include/linux/rcu_segcblist.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
> index 43e2935e8966..646759042333 100644
> --- a/include/linux/rcu_segcblist.h
> +++ b/include/linux/rcu_segcblist.h
> @@ -14,8 +14,8 @@
>  #ifndef __INCLUDE_LINUX_RCU_SEGCBLIST_H
>  #define __INCLUDE_LINUX_RCU_SEGCBLIST_H
>  
> -#include <uapi/asm-generic/types.h>
> -#include <asm-generic/atomic-long.h>
> +#include <linux/types.h>
> +#include <linux/atomic.h>
>  
>  /* Simple unsegmented callback lists. */
>  struct rcu_cblist {
> -- 
> 2.20.1
> 
> -- 
> Cheers,
> Stephen Rothwell



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

* Re: linux-next: build failure after merge of the rcu tree
  2019-08-13  7:57 Stephen Rothwell
@ 2019-08-13 15:31 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2019-08-13 15:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google),
	Greg Kroah-Hartman

On Tue, Aug 13, 2019 at 05:57:32PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (powerpc allnoconfig)
> failed like this:
> 
> drivers/base/core.c: In function 'device_links_read_lock_held':
> drivers/base/core.c:106:9: error: implicit declaration of function 'lock_is_held'; did you mean 'lockref_get'? [-Werror=implicit-function-declaration]
>   return lock_is_held(&device_links_lock);
>          ^~~~~~~~~~~~
>          lockref_get
> 
> Caused by commit
> 
>   4a3a5474b4c1 ("driver/core: Convert to use built-in RCU list checking")
> 
> lock_is_held() us only available if CONFIG_LOCKDEP is set.

Joel, one approach would be to make lock_is_held() variant of
device_links_read_lock_held() be a macro rather than a function.
Another would be to use #ifdef so as to invoke lock_is_held() only when
lockdep is enabled.

Or do you have a better approach?

							Thanx, Paul

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



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

* linux-next: build failure after merge of the rcu tree
@ 2019-08-13  7:57 Stephen Rothwell
  2019-08-13 15:31 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2019-08-13  7:57 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google),
	Greg Kroah-Hartman

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

Hi all,

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

drivers/base/core.c: In function 'device_links_read_lock_held':
drivers/base/core.c:106:9: error: implicit declaration of function 'lock_is_held'; did you mean 'lockref_get'? [-Werror=implicit-function-declaration]
  return lock_is_held(&device_links_lock);
         ^~~~~~~~~~~~
         lockref_get

Caused by commit

  4a3a5474b4c1 ("driver/core: Convert to use built-in RCU list checking")

lock_is_held() us only available if CONFIG_LOCKDEP is set.

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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2017-09-04  4:50 Stephen Rothwell
@ 2017-09-04 16:39 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-09-04 16:39 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

On Mon, Sep 04, 2017 at 02:50:45PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcutorture.ko] undefined!
> ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcuperf.ko] undefined!
> 
> Caused by commit
> 
>   909bd6e3d9e7 ("rcu: Suppress RCU CPU stall warnings while dumping trace")
> 
> I have reverted that commit for today.

Apologies, fixed.  Also belatedly reset rcu/next to cover only commits
destined for the merge window, which eliminates that commit and several
others.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-09-04  4:50 Stephen Rothwell
  2017-09-04 16:39 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-09-04  4:50 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Paul,

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

ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcutorture.ko] undefined!
ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcuperf.ko] undefined!

Caused by commit

  909bd6e3d9e7 ("rcu: Suppress RCU CPU stall warnings while dumping trace")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-28  4:25 Stephen Rothwell
@ 2017-08-28 17:50 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-08-28 17:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mathieu Desnoyers

On Mon, Aug 28, 2017 at 02:25:48PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from arch/arm/kernel/asm-offsets.c:14:0:
> include/linux/sched.h: In function 'membarrier_sched_out':
> include/linux/sched.h:1680:3: error: implicit declaration of function 'sync_core' [-Werror=implicit-function-declaration]
>    sync_core();
>    ^
> 
> Caused by commit
> 
>   0d6eb99818da ("membarrier: Provide register sync core cmd")
> 
> I have used the rcu tree from next-20170825 for today.

I have dropped this, and will likely re-add with the facility provided
or with an ARCH_ kconfig option.

Sorry for the hassle!

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-08-28  4:25 Stephen Rothwell
  2017-08-28 17:50 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-08-28  4:25 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mathieu Desnoyers

Hi Paul,

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

In file included from arch/arm/kernel/asm-offsets.c:14:0:
include/linux/sched.h: In function 'membarrier_sched_out':
include/linux/sched.h:1680:3: error: implicit declaration of function 'sync_core' [-Werror=implicit-function-declaration]
   sync_core();
   ^

Caused by commit

  0d6eb99818da ("membarrier: Provide register sync core cmd")

I have used the rcu tree from next-20170825 for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11 14:41     ` Peter Zijlstra
@ 2017-08-11 20:12       ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-08-11 20:12 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Aug 11, 2017 at 04:41:50PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:14:34AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> > > On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> > > 
> > > Looks like I need to rebase my patch on top of a9668cd6ee28, and
> > > than put an smp_mb__after_spinlock() between the lock and the unlock.
> > > 
> > > Peter, any objections to that approach?  Other suggestions?
> > 
> > Hurm.. I'll have to try and understand that comment there again it
> > seems.
> 
> OK, so per commit b5740f4b2cb3 ("sched: Fix ancient race in do_exit()")
> the race is with try_to_wake_up():
> 
> down_read()
> 	p->state = TASK_UNINTERRUPTIBLE;
> 
> 						try_to_wake_up(p)
> 							spin_lock(p->pi_lock);
> 							/* sees TASK_UNINTERRUPTIBLE */
> 							ttwu_remote()
> 	/* check stuff, no need to schedule() */
> 	p->state = TASK_RUNNING
> 
> 
> p->state = TASK_DEAD
> 
> 								p->state = TASK_RUNNING /* whoops! */
> 							spin_unlock(p->pi_lock);
> 
> __schedule(false);
> BUG();
> 
> 
> 
> 
> So given that, I think that:
> 
>   spin_lock(&current->pi_lock);
>   spin_unlock(&current->pi_lock);
> 
>   current->state = TASK_DEAD;
> 
> is sufficient. I don't see a need for an additional smp_mb here.
> 
> Either the concurrent ttwu is finished and we must observe its RUNNING
> store, or it will observe our RUNNING store.

Makes sense to me!  Please see below for the updated commit.

							Thanx, Paul

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

commit 23a9b748a3d27f67cdb078fcb891a920285e75d9
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Thu Jun 29 12:08:26 2017 -0700

    sched: Replace spin_unlock_wait() with lock/unlock pair
    
    There is no agreed-upon definition of spin_unlock_wait()'s semantics,
    and it appears that all callers could do just as well with a lock/unlock
    pair.  This commit therefore replaces the spin_unlock_wait() call in
    do_task_dead() with spin_lock() followed immediately by spin_unlock().
    This should be safe from a performance perspective because the lock is
    this tasks ->pi_lock, and this is called only after the task exits.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Andrea Parri <parri.andrea@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    [ paulmck: Drop smp_mb() based on Peter Zijlstra's analysis:
      http://lkml.kernel.org/r/20170811144150.26gowhxte7ri5fpk@hirez.programming.kicks-ass.net ]

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 17c667b427b4..5d22323ae099 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3352,8 +3352,8 @@ void __noreturn do_task_dead(void)
 	 * To avoid it, we have to wait for releasing tsk->pi_lock which
 	 * is held by try_to_wake_up()
 	 */
-	smp_mb();
-	raw_spin_unlock_wait(&current->pi_lock);
+	raw_spin_lock_irq(&current->pi_lock);
+	raw_spin_unlock_irq(&current->pi_lock);
 
 	/* Causes final put_task_struct in finish_task_switch(): */
 	__set_current_state(TASK_DEAD);

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11 14:39     ` Paul E. McKenney
@ 2017-08-11 14:45       ` Peter Zijlstra
  0 siblings, 0 replies; 101+ messages in thread
From: Peter Zijlstra @ 2017-08-11 14:45 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Aug 11, 2017 at 07:39:17AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 11, 2017 at 11:14:34AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> > > On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> > > 
> > > Looks like I need to rebase my patch on top of a9668cd6ee28, and
> > > than put an smp_mb__after_spinlock() between the lock and the unlock.
> > > 
> > > Peter, any objections to that approach?  Other suggestions?
> > 
> > Hurm.. I'll have to try and understand that comment there again it
> > seems.
> 
> My reasoning is as follows:
> 
> 1.	The critical section is empty, so any prior references
> 	would be ordered only against later critical sections.
> 
> 2.	A full barrier within the critical section will order those
> 	prior references against later critical sections just
> 	as easily as would one prior to the critical section.
> 
> Does that make sense, I should I have stayed away from the keyboard
> at this early hour?  ;-)

So I think we can do away with 2 because our prior and later stores have
an address dependency (they are to the same variable) and thus must be
ordered already.

Basically:

	CPU0				CPU1

	p->state = TASK_UNINTERRUPTIBLE;
					 try_to_wake_up(p)
	p->state = TASK_RUNNING
	spin_lock(&p->pi_lock);
	spin_unlock(&p->pi_lock);
	p->state = TASK_DEAD

Now, the ttwu(p) NO-OPs unless it sees (UN)INTERRUPTIBLE, so either
RUNNING or DEAD are fine. However if it sees (UN)INTERRUPTIBLE it will
do another (competing) RUNNING store which must not overwrite DEAD.

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11  9:14   ` Peter Zijlstra
  2017-08-11 14:39     ` Paul E. McKenney
@ 2017-08-11 14:41     ` Peter Zijlstra
  2017-08-11 20:12       ` Paul E. McKenney
  1 sibling, 1 reply; 101+ messages in thread
From: Peter Zijlstra @ 2017-08-11 14:41 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Aug 11, 2017 at 11:14:34AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> > 
> > Looks like I need to rebase my patch on top of a9668cd6ee28, and
> > than put an smp_mb__after_spinlock() between the lock and the unlock.
> > 
> > Peter, any objections to that approach?  Other suggestions?
> 
> Hurm.. I'll have to try and understand that comment there again it
> seems.

OK, so per commit b5740f4b2cb3 ("sched: Fix ancient race in do_exit()")
the race is with try_to_wake_up():

down_read()
	p->state = TASK_UNINTERRUPTIBLE;

						try_to_wake_up(p)
							spin_lock(p->pi_lock);
							/* sees TASK_UNINTERRUPTIBLE */
							ttwu_remote()
	/* check stuff, no need to schedule() */
	p->state = TASK_RUNNING


p->state = TASK_DEAD

								p->state = TASK_RUNNING /* whoops! */
							spin_unlock(p->pi_lock);

__schedule(false);
BUG();




So given that, I think that:

  spin_lock(&current->pi_lock);
  spin_unlock(&current->pi_lock);

  current->state = TASK_DEAD;

is sufficient. I don't see a need for an additional smp_mb here.

Either the concurrent ttwu is finished and we must observe its RUNNING
store, or it will observe our RUNNING store.

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11  9:14   ` Peter Zijlstra
@ 2017-08-11 14:39     ` Paul E. McKenney
  2017-08-11 14:45       ` Peter Zijlstra
  2017-08-11 14:41     ` Peter Zijlstra
  1 sibling, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2017-08-11 14:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Aug 11, 2017 at 11:14:34AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> > 
> > Looks like I need to rebase my patch on top of a9668cd6ee28, and
> > than put an smp_mb__after_spinlock() between the lock and the unlock.
> > 
> > Peter, any objections to that approach?  Other suggestions?
> 
> Hurm.. I'll have to try and understand that comment there again it
> seems.

My reasoning is as follows:

1.	The critical section is empty, so any prior references
	would be ordered only against later critical sections.

2.	A full barrier within the critical section will order those
	prior references against later critical sections just
	as easily as would one prior to the critical section.

Does that make sense, I should I have stayed away from the keyboard
at this early hour?  ;-)

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11  4:54 ` Paul E. McKenney
@ 2017-08-11  9:14   ` Peter Zijlstra
  2017-08-11 14:39     ` Paul E. McKenney
  2017-08-11 14:41     ` Peter Zijlstra
  0 siblings, 2 replies; 101+ messages in thread
From: Peter Zijlstra @ 2017-08-11  9:14 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> 
> Looks like I need to rebase my patch on top of a9668cd6ee28, and
> than put an smp_mb__after_spinlock() between the lock and the unlock.
> 
> Peter, any objections to that approach?  Other suggestions?

Hurm.. I'll have to try and understand that comment there again it
seems.

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-08-11  4:43 Stephen Rothwell
@ 2017-08-11  4:54 ` Paul E. McKenney
  2017-08-11  9:14   ` Peter Zijlstra
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2017-08-11  4:54 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 Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/sched/core.c: In function 'do_task_dead':
> kernel/sched/core.c:3385:2: error: implicit declaration of function 'smp_mb__before_spinlock' [-Werror=implicit-function-declaration]
>   smp_mb__before_spinlock();
>   ^
> cc1: some warnings being treated as errors
> 
> Caused by commit
> 
>   4a6fc6107e90 ("sched: Replace spin_unlock_wait() with lock/unlock pair")
> 
> Interacting with commit
> 
>   a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")
> 
> from the tip tree.
> 
> I applied this patch for now, but I assume something better is required.

Looks like I need to rebase my patch on top of a9668cd6ee28, and
than put an smp_mb__after_spinlock() between the lock and the unlock.

Peter, any objections to that approach?  Other suggestions?

							Thanx, Paul

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 11 Aug 2017 14:32:10 +1000
> Subject: [PATCH] sched: temporary hack for locking: Remove smp_mb__before_spinlock()
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  kernel/sched/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2bd00feaea15..a4f4ba2e3be6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3382,7 +3382,7 @@ void __noreturn do_task_dead(void)
>  	 * To avoid it, we have to wait for releasing tsk->pi_lock which
>  	 * is held by try_to_wake_up()
>  	 */
> -	smp_mb__before_spinlock();
> +	smp_mb();
>  	raw_spin_lock_irq(&current->pi_lock);
>  	raw_spin_unlock_irq(&current->pi_lock);
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

* linux-next: build failure after merge of the rcu tree
@ 2017-08-11  4:43 Stephen Rothwell
  2017-08-11  4:54 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-08-11  4:43 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Paul,

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

kernel/sched/core.c: In function 'do_task_dead':
kernel/sched/core.c:3385:2: error: implicit declaration of function 'smp_mb__before_spinlock' [-Werror=implicit-function-declaration]
  smp_mb__before_spinlock();
  ^
cc1: some warnings being treated as errors

Caused by commit

  4a6fc6107e90 ("sched: Replace spin_unlock_wait() with lock/unlock pair")

Interacting with commit

  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

from the tip tree.

I applied this patch for now, but I assume something better is required.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Aug 2017 14:32:10 +1000
Subject: [PATCH] sched: temporary hack for locking: Remove smp_mb__before_spinlock()

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

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2bd00feaea15..a4f4ba2e3be6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3382,7 +3382,7 @@ void __noreturn do_task_dead(void)
 	 * To avoid it, we have to wait for releasing tsk->pi_lock which
 	 * is held by try_to_wake_up()
 	 */
-	smp_mb__before_spinlock();
+	smp_mb();
 	raw_spin_lock_irq(&current->pi_lock);
 	raw_spin_unlock_irq(&current->pi_lock);
 
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-30  4:10   ` Michael Ellerman
@ 2017-06-02 17:51     ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-06-02 17:51 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Joe Perches, Mike Frysinger,
	Steven Miao

On Tue, May 30, 2017 at 02:10:26PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > On Mon, May 29, 2017 at 04:02:09PM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >> 
> >> After merging the rcu tree, today's linux-next build (bfin
> >> BF526-EZBRD_defconfig and several other bfin configs) failed like this:
> >> 
> >> In file included from include/linux/srcu.h:60:0,
> >>                  from include/linux/notifier.h:15,
> >>                  from include/linux/memory_hotplug.h:6,
> >>                  from include/linux/mmzone.h:777,
> >>                  from include/linux/gfp.h:5,
> >>                  from include/linux/kmod.h:22,
> >>                  from include/linux/module.h:13,
> >>                  from include/linux/moduleloader.h:5,
> >>                  from arch/blackfin/kernel/module.c:9:
> >> include/linux/srcutiny.h: In function 'srcu_torture_stats_print':
> >> include/linux/srcutiny.h:96:2: error: 'mod' undeclared (first use in this function)
> >> 
> >> Caused by commit
> >> 
> >>   54ffb22bd841 ("rcutorture: Move SRCU status printing to SRCU implementations")
> >
> > And of course this is nothing but a printk().
> 
> Ah but it's not, it's a pr_alert():
> 
> +       pr_alert("%s%s Tiny SRCU per-CPU(idx=%d): (%hd,%hd)\n",
> +                tt, tf, idx,
> +                READ_ONCE(sp->srcu_lock_nesting[!idx]),
> +                READ_ONCE(sp->srcu_lock_nesting[idx]));
> 
> Where pr_alert() is:
> 
> #define pr_alert(fmt, ...) \
> 	printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
> 
> 
> So that's where pr_fmt() is coming into it.
> 
> And if any code in module.c called srcu_torture_stats_print(), it would
> actually claim to come from "module: ", which would be confusing.
> 
> I don't think you use pr_fmt() in the RCU code, so you could skip using
> pr_alert() and just use printk(KERN_ALERT "...") and get the same
> result, without any interactions with pr_fmt().

Does the following patch fix things for you?

							Thanx, Paul

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

commit 7eb8d998d3f66851c0d25abcdb2d737edc6a21ed
Author: Joe Perches <joe@perches.com>
Date:   Tue May 30 15:20:37 2017 -0700

    module: Fix pr_fmt() bug for header use of printk
    
    This commit removes the pr_fmt() macro, replacing it with mod_err() and
    mod_debug() macros to avoid errors when using printk() from header files.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/arch/blackfin/kernel/module.c b/arch/blackfin/kernel/module.c
index 0188c933b155..15af5768c403 100644
--- a/arch/blackfin/kernel/module.c
+++ b/arch/blackfin/kernel/module.c
@@ -4,8 +4,6 @@
  * Licensed under the GPL-2 or later
  */
 
-#define pr_fmt(fmt) "module %s: " fmt, mod->name
-
 #include <linux/moduleloader.h>
 #include <linux/elf.h>
 #include <linux/vmalloc.h>
@@ -16,6 +14,11 @@
 #include <asm/cacheflush.h>
 #include <linux/uaccess.h>
 
+#define mod_err(mod, fmt, ...)						\
+	pr_err("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
+#define mod_debug(mod, fmt, ...)					\
+	pr_debug("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
+
 /* Transfer the section to the L1 memory */
 int
 module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
@@ -44,7 +47,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_inst_sram_alloc(s->sh_size);
 			mod->arch.text_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 inst memory allocation failed\n");
+				mod_err(mod, "L1 inst memory allocation failed\n");
 				return -1;
 			}
 			dma_memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -56,7 +59,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_alloc(s->sh_size);
 			mod->arch.data_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -68,7 +71,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_zalloc(s->sh_size);
 			mod->arch.bss_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 
@@ -77,7 +80,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.data_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -87,7 +90,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.bss_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memset(dest, 0, s->sh_size);
@@ -99,7 +102,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.text_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -111,7 +114,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.data_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -123,7 +126,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_zalloc(s->sh_size);
 			mod->arch.bss_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 
@@ -157,8 +160,8 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 	Elf32_Sym *sym;
 	unsigned long location, value, size;
 
-	pr_debug("applying relocate section %u to %u\n",
-		relsec, sechdrs[relsec].sh_info);
+	mod_debug(mod, "applying relocate section %u to %u\n",
+		  relsec, sechdrs[relsec].sh_info);
 
 	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
 		/* This is where to make the change */
@@ -174,14 +177,14 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 
 #ifdef CONFIG_SMP
 		if (location >= COREB_L1_DATA_A_START) {
-			pr_err("cannot relocate in L1: %u (SMP kernel)\n",
+			mod_err(mod, "cannot relocate in L1: %u (SMP kernel)\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
 #endif
 
-		pr_debug("location is %lx, value is %lx type is %d\n",
-			location, value, ELF32_R_TYPE(rel[i].r_info));
+		mod_debug(mod, "location is %lx, value is %lx type is %d\n",
+			  location, value, ELF32_R_TYPE(rel[i].r_info));
 
 		switch (ELF32_R_TYPE(rel[i].r_info)) {
 
@@ -200,12 +203,12 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 		case R_BFIN_PCREL12_JUMP:
 		case R_BFIN_PCREL12_JUMP_S:
 		case R_BFIN_PCREL10:
-			pr_err("unsupported relocation: %u (no -mlong-calls?)\n",
+			mod_err(mod, "unsupported relocation: %u (no -mlong-calls?)\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 
 		default:
-			pr_err("unknown relocation: %u\n",
+			mod_err(mod, "unknown relocation: %u\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
@@ -222,7 +225,7 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 			isram_memcpy((void *)location, &value, size);
 			break;
 		default:
-			pr_err("invalid relocation for %#lx\n", location);
+			mod_err(mod, "invalid relocation for %#lx\n", location);
 			return -ENOEXEC;
 		}
 	}

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-29 21:15 ` Paul E. McKenney
  2017-05-30  1:40   ` Stephen Rothwell
@ 2017-05-30  4:10   ` Michael Ellerman
  2017-06-02 17:51     ` Paul E. McKenney
  1 sibling, 1 reply; 101+ messages in thread
From: Michael Ellerman @ 2017-05-30  4:10 UTC (permalink / raw)
  To: paulmck, Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
	Mike Frysinger, Steven Miao

"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:

> On Mon, May 29, 2017 at 04:02:09PM +1000, Stephen Rothwell wrote:
>> Hi Paul,
>> 
>> After merging the rcu tree, today's linux-next build (bfin
>> BF526-EZBRD_defconfig and several other bfin configs) failed like this:
>> 
>> In file included from include/linux/srcu.h:60:0,
>>                  from include/linux/notifier.h:15,
>>                  from include/linux/memory_hotplug.h:6,
>>                  from include/linux/mmzone.h:777,
>>                  from include/linux/gfp.h:5,
>>                  from include/linux/kmod.h:22,
>>                  from include/linux/module.h:13,
>>                  from include/linux/moduleloader.h:5,
>>                  from arch/blackfin/kernel/module.c:9:
>> include/linux/srcutiny.h: In function 'srcu_torture_stats_print':
>> include/linux/srcutiny.h:96:2: error: 'mod' undeclared (first use in this function)
>> 
>> Caused by commit
>> 
>>   54ffb22bd841 ("rcutorture: Move SRCU status printing to SRCU implementations")
>
> And of course this is nothing but a printk().

Ah but it's not, it's a pr_alert():

+       pr_alert("%s%s Tiny SRCU per-CPU(idx=%d): (%hd,%hd)\n",
+                tt, tf, idx,
+                READ_ONCE(sp->srcu_lock_nesting[!idx]),
+                READ_ONCE(sp->srcu_lock_nesting[idx]));

Where pr_alert() is:

#define pr_alert(fmt, ...) \
	printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)


So that's where pr_fmt() is coming into it.

And if any code in module.c called srcu_torture_stats_print(), it would
actually claim to come from "module: ", which would be confusing.

I don't think you use pr_fmt() in the RCU code, so you could skip using
pr_alert() and just use printk(KERN_ALERT "...") and get the same
result, without any interactions with pr_fmt().

cheers

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-30  2:20         ` Joe Perches
@ 2017-05-30  3:13           ` Stephen Rothwell
  0 siblings, 0 replies; 101+ messages in thread
From: Stephen Rothwell @ 2017-05-30  3:13 UTC (permalink / raw)
  To: Joe Perches
  Cc: paulmck, Linux-Next Mailing List, Linux Kernel Mailing List,
	Mike Frysinger, Steven Miao

Hi Joe,

On Mon, 29 May 2017 19:20:25 -0700 Joe Perches <joe@perches.com> wrote:
>
> On Mon, 2017-05-29 at 19:14 -0700, Paul E. McKenney wrote:
> > On Mon, May 29, 2017 at 06:54:26PM -0700, Joe Perches wrote:  
> > > On Tue, 2017-05-30 at 11:40 +1000, Stephen Rothwell wrote:  
> > > > Hi Paul,
> > > >   
> > > > > On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > > > 
> > > > > Anyone see any other options?  
> > > 
> > > My preferred option would be removing pr_fmt
> > > and adding a couple new macros.  
> > 
> > Not sure how to evaluate yours and Stephen's changes, but I reverted my
> > conversion to a macro based on the hope that something good will come
> > of this effort.  ;-)  
> 
> Stephen's suggestion makes the format and arguments
> have an apparent mismatch.  What I suggested hides
> the "module %s: ", mod->name bit in the macros (like
> the older pr_fmt use), allows anyone else to #define
> pr_fmt to taste, and keeps the format and arguments in
> agreement.

Yours is much better, mine was just a quick hack ... consider yours

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

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-30  2:14       ` Paul E. McKenney
@ 2017-05-30  2:20         ` Joe Perches
  2017-05-30  3:13           ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Joe Perches @ 2017-05-30  2:20 UTC (permalink / raw)
  To: paulmck
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Mike Frysinger, Steven Miao

On Mon, 2017-05-29 at 19:14 -0700, Paul E. McKenney wrote:
> On Mon, May 29, 2017 at 06:54:26PM -0700, Joe Perches wrote:
> > On Tue, 2017-05-30 at 11:40 +1000, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > > On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > > 
> > > > Anyone see any other options?
> > 
> > My preferred option would be removing pr_fmt
> > and adding a couple new macros.
> 
> Not sure how to evaluate yours and Stephen's changes, but I reverted my
> conversion to a macro based on the hope that something good will come
> of this effort.  ;-)

Stephen's suggestion makes the format and arguments
have an apparent mismatch.  What I suggested hides
the "module %s: ", mod->name bit in the macros (like
the older pr_fmt use), allows anyone else to #define
pr_fmt to taste, and keeps the format and arguments in
agreement.

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-30  1:54     ` Joe Perches
@ 2017-05-30  2:14       ` Paul E. McKenney
  2017-05-30  2:20         ` Joe Perches
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2017-05-30  2:14 UTC (permalink / raw)
  To: Joe Perches
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Mike Frysinger, Steven Miao

On Mon, May 29, 2017 at 06:54:26PM -0700, Joe Perches wrote:
> On Tue, 2017-05-30 at 11:40 +1000, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > > On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > 
> > > Anyone see any other options?
> 
> My preferred option would be removing pr_fmt
> and adding a couple new macros.

Not sure how to evaluate yours and Stephen's changes, but I reverted my
conversion to a macro based on the hope that something good will come
of this effort.  ;-)

							Thanx, Paul

> ---
>  arch/blackfin/kernel/module.c | 39 +++++++++++++++++++++------------------
>  1 file changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/blackfin/kernel/module.c b/arch/blackfin/kernel/module.c
> index 0188c933b155..e43aec7eb8d3 100644
> --- a/arch/blackfin/kernel/module.c
> +++ b/arch/blackfin/kernel/module.c
> @@ -4,8 +4,6 @@
>   * Licensed under the GPL-2 or later
>   */
>  
> -#define pr_fmt(fmt) "module %s: " fmt, mod->name
> -
>  #include <linux/moduleloader.h>
>  #include <linux/elf.h>
>  #include <linux/vmalloc.h>
> @@ -16,6 +14,11 @@
>  #include <asm/cacheflush.h>
>  #include <linux/uaccess.h>
>  
> +#define mod_err(mod, fmt, ...)						\
> +	pr_err("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
> +#define mod_debug(mod, ...)						\
> +	pr_debug("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
> +
>  /* Transfer the section to the L1 memory */
>  int
>  module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> @@ -44,7 +47,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l1_inst_sram_alloc(s->sh_size);
>  			mod->arch.text_l1 = dest;
>  			if (dest == NULL) {
> -				pr_err("L1 inst memory allocation failed\n");
> +				mod_err(mod, "L1 inst memory allocation failed\n");
>  				return -1;
>  			}
>  			dma_memcpy(dest, (void *)s->sh_addr, s->sh_size);
> @@ -56,7 +59,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l1_data_sram_alloc(s->sh_size);
>  			mod->arch.data_a_l1 = dest;
>  			if (dest == NULL) {
> -				pr_err("L1 data memory allocation failed\n");
> +				mod_err(mod, "L1 data memory allocation failed\n");
>  				return -1;
>  			}
>  			memcpy(dest, (void *)s->sh_addr, s->sh_size);
> @@ -68,7 +71,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l1_data_sram_zalloc(s->sh_size);
>  			mod->arch.bss_a_l1 = dest;
>  			if (dest == NULL) {
> -				pr_err("L1 data memory allocation failed\n");
> +				mod_err(mod, "L1 data memory allocation failed\n");
>  				return -1;
>  			}
>  
> @@ -77,7 +80,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l1_data_B_sram_alloc(s->sh_size);
>  			mod->arch.data_b_l1 = dest;
>  			if (dest == NULL) {
> -				pr_err("L1 data memory allocation failed\n");
> +				mod_err(mod, "L1 data memory allocation failed\n");
>  				return -1;
>  			}
>  			memcpy(dest, (void *)s->sh_addr, s->sh_size);
> @@ -87,7 +90,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l1_data_B_sram_alloc(s->sh_size);
>  			mod->arch.bss_b_l1 = dest;
>  			if (dest == NULL) {
> -				pr_err("L1 data memory allocation failed\n");
> +				mod_err(mod, "L1 data memory allocation failed\n");
>  				return -1;
>  			}
>  			memset(dest, 0, s->sh_size);
> @@ -99,7 +102,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l2_sram_alloc(s->sh_size);
>  			mod->arch.text_l2 = dest;
>  			if (dest == NULL) {
> -				pr_err("L2 SRAM allocation failed\n");
> +				mod_err(mod, "L2 SRAM allocation failed\n");
>  				return -1;
>  			}
>  			memcpy(dest, (void *)s->sh_addr, s->sh_size);
> @@ -111,7 +114,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l2_sram_alloc(s->sh_size);
>  			mod->arch.data_l2 = dest;
>  			if (dest == NULL) {
> -				pr_err("L2 SRAM allocation failed\n");
> +				mod_err(mod, "L2 SRAM allocation failed\n");
>  				return -1;
>  			}
>  			memcpy(dest, (void *)s->sh_addr, s->sh_size);
> @@ -123,7 +126,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
>  			dest = l2_sram_zalloc(s->sh_size);
>  			mod->arch.bss_l2 = dest;
>  			if (dest == NULL) {
> -				pr_err("L2 SRAM allocation failed\n");
> +				mod_err(mod, "L2 SRAM allocation failed\n");
>  				return -1;
>  			}
>  
> @@ -157,8 +160,8 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>  	Elf32_Sym *sym;
>  	unsigned long location, value, size;
>  
> -	pr_debug("applying relocate section %u to %u\n",
> -		relsec, sechdrs[relsec].sh_info);
> +	mod_debug(mod, "applying relocate section %u to %u\n",
> +		  relsec, sechdrs[relsec].sh_info);
>  
>  	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
>  		/* This is where to make the change */
> @@ -174,14 +177,14 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>  
>  #ifdef CONFIG_SMP
>  		if (location >= COREB_L1_DATA_A_START) {
> -			pr_err("cannot relocate in L1: %u (SMP kernel)\n",
> +			mod_err(mod, "cannot relocate in L1: %u (SMP kernel)\n",
>  				ELF32_R_TYPE(rel[i].r_info));
>  			return -ENOEXEC;
>  		}
>  #endif
>  
> -		pr_debug("location is %lx, value is %lx type is %d\n",
> -			location, value, ELF32_R_TYPE(rel[i].r_info));
> +		mod_debug(mod, "location is %lx, value is %lx type is %d\n",
> +			  location, value, ELF32_R_TYPE(rel[i].r_info));
>  
>  		switch (ELF32_R_TYPE(rel[i].r_info)) {
>  
> @@ -200,12 +203,12 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>  		case R_BFIN_PCREL12_JUMP:
>  		case R_BFIN_PCREL12_JUMP_S:
>  		case R_BFIN_PCREL10:
> -			pr_err("unsupported relocation: %u (no -mlong-calls?)\n",
> +			mod_err(mod, "unsupported relocation: %u (no -mlong-calls?)\n",
>  				ELF32_R_TYPE(rel[i].r_info));
>  			return -ENOEXEC;
>  
>  		default:
> -			pr_err("unknown relocation: %u\n",
> +			mod_err(mod, "unknown relocation: %u\n",
>  				ELF32_R_TYPE(rel[i].r_info));
>  			return -ENOEXEC;
>  		}
> @@ -222,7 +225,7 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>  			isram_memcpy((void *)location, &value, size);
>  			break;
>  		default:
> -			pr_err("invalid relocation for %#lx\n", location);
> +			mod_err(mod, "invalid relocation for %#lx\n", location);
>  			return -ENOEXEC;
>  		}
>  	}
> 

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-30  1:40   ` Stephen Rothwell
@ 2017-05-30  1:54     ` Joe Perches
  2017-05-30  2:14       ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Joe Perches @ 2017-05-30  1:54 UTC (permalink / raw)
  To: Stephen Rothwell, Paul E. McKenney
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Mike Frysinger, Steven Miao

On Tue, 2017-05-30 at 11:40 +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> > On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > Anyone see any other options?

My preferred option would be removing pr_fmt
and adding a couple new macros.
---
 arch/blackfin/kernel/module.c | 39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/arch/blackfin/kernel/module.c b/arch/blackfin/kernel/module.c
index 0188c933b155..e43aec7eb8d3 100644
--- a/arch/blackfin/kernel/module.c
+++ b/arch/blackfin/kernel/module.c
@@ -4,8 +4,6 @@
  * Licensed under the GPL-2 or later
  */
 
-#define pr_fmt(fmt) "module %s: " fmt, mod->name
-
 #include <linux/moduleloader.h>
 #include <linux/elf.h>
 #include <linux/vmalloc.h>
@@ -16,6 +14,11 @@
 #include <asm/cacheflush.h>
 #include <linux/uaccess.h>
 
+#define mod_err(mod, fmt, ...)						\
+	pr_err("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
+#define mod_debug(mod, ...)						\
+	pr_debug("module %s: " fmt, (mod)->name, ##__VA_ARGS__)
+
 /* Transfer the section to the L1 memory */
 int
 module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
@@ -44,7 +47,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_inst_sram_alloc(s->sh_size);
 			mod->arch.text_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 inst memory allocation failed\n");
+				mod_err(mod, "L1 inst memory allocation failed\n");
 				return -1;
 			}
 			dma_memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -56,7 +59,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_alloc(s->sh_size);
 			mod->arch.data_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -68,7 +71,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_zalloc(s->sh_size);
 			mod->arch.bss_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 
@@ -77,7 +80,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.data_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -87,7 +90,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.bss_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				mod_err(mod, "L1 data memory allocation failed\n");
 				return -1;
 			}
 			memset(dest, 0, s->sh_size);
@@ -99,7 +102,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.text_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -111,7 +114,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.data_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -123,7 +126,7 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_zalloc(s->sh_size);
 			mod->arch.bss_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				mod_err(mod, "L2 SRAM allocation failed\n");
 				return -1;
 			}
 
@@ -157,8 +160,8 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 	Elf32_Sym *sym;
 	unsigned long location, value, size;
 
-	pr_debug("applying relocate section %u to %u\n",
-		relsec, sechdrs[relsec].sh_info);
+	mod_debug(mod, "applying relocate section %u to %u\n",
+		  relsec, sechdrs[relsec].sh_info);
 
 	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
 		/* This is where to make the change */
@@ -174,14 +177,14 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 
 #ifdef CONFIG_SMP
 		if (location >= COREB_L1_DATA_A_START) {
-			pr_err("cannot relocate in L1: %u (SMP kernel)\n",
+			mod_err(mod, "cannot relocate in L1: %u (SMP kernel)\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
 #endif
 
-		pr_debug("location is %lx, value is %lx type is %d\n",
-			location, value, ELF32_R_TYPE(rel[i].r_info));
+		mod_debug(mod, "location is %lx, value is %lx type is %d\n",
+			  location, value, ELF32_R_TYPE(rel[i].r_info));
 
 		switch (ELF32_R_TYPE(rel[i].r_info)) {
 
@@ -200,12 +203,12 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 		case R_BFIN_PCREL12_JUMP:
 		case R_BFIN_PCREL12_JUMP_S:
 		case R_BFIN_PCREL10:
-			pr_err("unsupported relocation: %u (no -mlong-calls?)\n",
+			mod_err(mod, "unsupported relocation: %u (no -mlong-calls?)\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 
 		default:
-			pr_err("unknown relocation: %u\n",
+			mod_err(mod, "unknown relocation: %u\n",
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
@@ -222,7 +225,7 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 			isram_memcpy((void *)location, &value, size);
 			break;
 		default:
-			pr_err("invalid relocation for %#lx\n", location);
+			mod_err(mod, "invalid relocation for %#lx\n", location);
 			return -ENOEXEC;
 		}
 	}

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-29 21:15 ` Paul E. McKenney
@ 2017-05-30  1:40   ` Stephen Rothwell
  2017-05-30  1:54     ` Joe Perches
  2017-05-30  4:10   ` Michael Ellerman
  1 sibling, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-05-30  1:40 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
	Mike Frysinger, Steven Miao

Hi Paul,

On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Anyone see any other options?

I will add the following to linux-next today.  If the Blackfin guys
agree (or come up with something better), you should get their acks and
then add it to your tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 30 May 2017 09:21:05 +1000
Subject: [PATCH] Revert "Blackfin: use more standard pr_fmt in the module loader"

This reverts commit b75a9e6bfba5c7343391ac1bacd44d6652dde8da.

It turns out (after all this time) that referencing a function parameter
from a global macro was a bit fragile.

This could probably be done better, but this fixes a build failure due
to a commit that adds a use of pr_alert in an include file.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/blackfin/kernel/module.c | 41 +++++++++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/arch/blackfin/kernel/module.c b/arch/blackfin/kernel/module.c
index 0188c933b155..adbbccc91fa1 100644
--- a/arch/blackfin/kernel/module.c
+++ b/arch/blackfin/kernel/module.c
@@ -4,7 +4,7 @@
  * Licensed under the GPL-2 or later
  */
 
-#define pr_fmt(fmt) "module %s: " fmt, mod->name
+#define pr_fmt(fmt) "module %s: " fmt
 
 #include <linux/moduleloader.h>
 #include <linux/elf.h>
@@ -44,7 +44,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_inst_sram_alloc(s->sh_size);
 			mod->arch.text_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 inst memory allocation failed\n");
+				pr_err("L1 inst memory allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			dma_memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -56,7 +57,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_alloc(s->sh_size);
 			mod->arch.data_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				pr_err("L1 data memory allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -68,7 +70,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_sram_zalloc(s->sh_size);
 			mod->arch.bss_a_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				pr_err("L1 data memory allocation failed\n",
+					mod->name);
 				return -1;
 			}
 
@@ -77,7 +80,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.data_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				pr_err("L1 data memory allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -87,7 +91,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l1_data_B_sram_alloc(s->sh_size);
 			mod->arch.bss_b_l1 = dest;
 			if (dest == NULL) {
-				pr_err("L1 data memory allocation failed\n");
+				pr_err("L1 data memory allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			memset(dest, 0, s->sh_size);
@@ -99,7 +104,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.text_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				pr_err("L2 SRAM allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -111,7 +117,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_alloc(s->sh_size);
 			mod->arch.data_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				pr_err("L2 SRAM allocation failed\n",
+					mod->name);
 				return -1;
 			}
 			memcpy(dest, (void *)s->sh_addr, s->sh_size);
@@ -123,7 +130,8 @@ module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			dest = l2_sram_zalloc(s->sh_size);
 			mod->arch.bss_l2 = dest;
 			if (dest == NULL) {
-				pr_err("L2 SRAM allocation failed\n");
+				pr_err("L2 SRAM allocation failed\n",
+					mod->name);
 				return -1;
 			}
 
@@ -157,7 +165,7 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 	Elf32_Sym *sym;
 	unsigned long location, value, size;
 
-	pr_debug("applying relocate section %u to %u\n",
+	pr_debug("applying relocate section %u to %u\n", mod->name,
 		relsec, sechdrs[relsec].sh_info);
 
 	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
@@ -174,14 +182,14 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 
 #ifdef CONFIG_SMP
 		if (location >= COREB_L1_DATA_A_START) {
-			pr_err("cannot relocate in L1: %u (SMP kernel)\n",
-				ELF32_R_TYPE(rel[i].r_info));
+			pr_err("cannot relocate in L1: %u (SMP kernel)",
+				mod->name, ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
 #endif
 
 		pr_debug("location is %lx, value is %lx type is %d\n",
-			location, value, ELF32_R_TYPE(rel[i].r_info));
+			mod->name, location, value, ELF32_R_TYPE(rel[i].r_info));
 
 		switch (ELF32_R_TYPE(rel[i].r_info)) {
 
@@ -201,11 +209,11 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 		case R_BFIN_PCREL12_JUMP_S:
 		case R_BFIN_PCREL10:
 			pr_err("unsupported relocation: %u (no -mlong-calls?)\n",
-				ELF32_R_TYPE(rel[i].r_info));
+				mod->name, ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 
 		default:
-			pr_err("unknown relocation: %u\n",
+			pr_err("unknown relocation: %u\n", mod->name,
 				ELF32_R_TYPE(rel[i].r_info));
 			return -ENOEXEC;
 		}
@@ -222,7 +230,8 @@ apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 			isram_memcpy((void *)location, &value, size);
 			break;
 		default:
-			pr_err("invalid relocation for %#lx\n", location);
+			pr_err("invalid relocation for %#lx\n",
+				mod->name, location);
 			return -ENOEXEC;
 		}
 	}
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-05-29  6:02 Stephen Rothwell
@ 2017-05-29 21:15 ` Paul E. McKenney
  2017-05-30  1:40   ` Stephen Rothwell
  2017-05-30  4:10   ` Michael Ellerman
  0 siblings, 2 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-05-29 21:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
	Mike Frysinger, Steven Miao

On Mon, May 29, 2017 at 04:02:09PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (bfin
> BF526-EZBRD_defconfig and several other bfin configs) failed like this:
> 
> In file included from include/linux/srcu.h:60:0,
>                  from include/linux/notifier.h:15,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:777,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from include/linux/moduleloader.h:5,
>                  from arch/blackfin/kernel/module.c:9:
> include/linux/srcutiny.h: In function 'srcu_torture_stats_print':
> include/linux/srcutiny.h:96:2: error: 'mod' undeclared (first use in this function)
> 
> Caused by commit
> 
>   54ffb22bd841 ("rcutorture: Move SRCU status printing to SRCU implementations")

And of course this is nothing but a printk().

> arch/blackfin/kernel/module.c includes this:
> 
> #define pr_fmt(fmt) "module %s: " fmt, mod->name

Hmmm...  There are well over 1000 definitions of pr_fmt() in the kernel.
Very popular name there!

> added by commit
> 
>   b75a9e6bfba5 ("Blackfin: use more standard pr_fmt in the module loader")
> 
> before v2.6.39-rc2 ...

I guess I cannot claim to be blindsided by a recent change, at least not
unless you take my age into account.  ;-)

So maybe there is some header file that blackfin wants included?  There
are only about 100 definitions of "mod", so let's see...  Well, none of
them are in blackfin, but perhaps the two in module.h?  But these are just
fields in structs.  As is the one in moduleparam.h.

At this point, the only option I see is to convert srcu_torture_stats_print()
from a static inline function to a macro.

Anyone see any other options?

								Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-05-29  6:02 Stephen Rothwell
  2017-05-29 21:15 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-05-29  6:02 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
	Mike Frysinger, Steven Miao

Hi Paul,

After merging the rcu tree, today's linux-next build (bfin
BF526-EZBRD_defconfig and several other bfin configs) failed like this:

In file included from include/linux/srcu.h:60:0,
                 from include/linux/notifier.h:15,
                 from include/linux/memory_hotplug.h:6,
                 from include/linux/mmzone.h:777,
                 from include/linux/gfp.h:5,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from include/linux/moduleloader.h:5,
                 from arch/blackfin/kernel/module.c:9:
include/linux/srcutiny.h: In function 'srcu_torture_stats_print':
include/linux/srcutiny.h:96:2: error: 'mod' undeclared (first use in this function)

Caused by commit

  54ffb22bd841 ("rcutorture: Move SRCU status printing to SRCU implementations")

arch/blackfin/kernel/module.c includes this:

#define pr_fmt(fmt) "module %s: " fmt, mod->name

added by commit

  b75a9e6bfba5 ("Blackfin: use more standard pr_fmt in the module loader")

before v2.6.39-rc2 ...

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-04-20  5:36 Stephen Rothwell
@ 2017-04-20 14:23 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-04-20 14:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Michael Ellerman, Benjamin Herrenschmidt, PowerPC

On Thu, Apr 20, 2017 at 03:36:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> [Also reported by Michael elsewhere]
> 
> After merging the rcu tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
> 
> arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:587: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range (0x0000000000009d88 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:619: Error: operand out of range (0x0000000000009dc0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:643: Error: operand out of range (0x0000000000009df8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:650: Error: operand out of range (0x0000000000009d8c is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1353: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1663: Error: operand out of range (0x0000000000009db0 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1665: Error: operand out of range (0x0000000000009dc8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1734: Error: operand out of range (0x0000000000009db8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1782: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1837: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1877: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1918: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1943: Error: operand out of range (0x000000000000a048 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> 
> Caused by commit
> 
>   b2bb79507ba1 ("srcu: Parallelize callback handling")
> 
> I have left it broken for today.

Well, I guess I made good on my promise to break this in a more subtle
and creative way...  :-/

Please let me know what you need me to do.  I suppose that I could
push part of the srcu_struct into another structure and dynamically
allocate it, but that sounds a bit ugly...

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-04-20  5:36 Stephen Rothwell
  2017-04-20 14:23 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-04-20  5:36 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Michael Ellerman, Benjamin Herrenschmidt, PowerPC

Hi Paul,

[Also reported by Michael elsewhere]

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

arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
arch/powerpc/kvm/book3s_hv_rmhandlers.S:587: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range (0x0000000000009d88 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:619: Error: operand out of range (0x0000000000009dc0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:643: Error: operand out of range (0x0000000000009df8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:650: Error: operand out of range (0x0000000000009d8c is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1353: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1663: Error: operand out of range (0x0000000000009db0 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1665: Error: operand out of range (0x0000000000009dc8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1734: Error: operand out of range (0x0000000000009db8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1782: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1837: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1877: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1918: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1943: Error: operand out of range (0x000000000000a048 is not between 0xffffffffffff8000 and 0x0000000000007ffc)

Caused by commit

  b2bb79507ba1 ("srcu: Parallelize callback handling")

I have left it broken for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-04-19  4:06 ` Paul E. McKenney
@ 2017-04-19  5:45   ` Stephen Rothwell
  0 siblings, 0 replies; 101+ messages in thread
From: Stephen Rothwell @ 2017-04-19  5:45 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Paul,

On Tue, 18 Apr 2017 21:06:20 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Or at least broken in a more subtle and creative way.  ;-)

What I live for :-)

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-04-19  3:50 Stephen Rothwell
@ 2017-04-19  4:06 ` Paul E. McKenney
  2017-04-19  5:45   ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2017-04-19  4:06 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

On Wed, Apr 19, 2017 at 01:50:16PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> kernel/rcu/rcutorture.c: In function 'rcu_torture_stats_print':
> kernel/rcu/rcutorture.c:1369:3: error: implicit declaration of function 'srcutorture_get_gp_data' [-Werror=implicit-function-declaration]
>    srcutorture_get_gp_data(cur_ops->ttype, srcu_ctlp,
>    ^
> 
> Caused by commit
> 
>   b4d55cac0a93 ("srcu: Make rcutorture writer stalls print SRCU GP state")
> 
> This config has CONFIG_CLASSIC_SRCU=y and CONFIG_RCU_TORTURE_TEST=m, so
> CONFIG_RCU_TORTURE_TEST is not defined - CONFIG_RCU_TORTURE_TEST_MODULE
> is defined.  You probably want to protect srcutorture_get_gp_data() with
> IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instead.
> 
> I have used the rcu tree from next-20170418 for today.

Please accept my apologies!  I forgot about the state of -rcu while
chasing another bug, and only a few minutes ago made the transition
from "Why doesn't this code work?" to "Why didn't my brain work?".  :-/

Will be fixed for tomorrow's -next.  Or at least broken in a more subtle
and creative way.  ;-)

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-04-19  3:50 Stephen Rothwell
  2017-04-19  4:06 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-04-19  3:50 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Paul,

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

kernel/rcu/rcutorture.c: In function 'rcu_torture_stats_print':
kernel/rcu/rcutorture.c:1369:3: error: implicit declaration of function 'srcutorture_get_gp_data' [-Werror=implicit-function-declaration]
   srcutorture_get_gp_data(cur_ops->ttype, srcu_ctlp,
   ^

Caused by commit

  b4d55cac0a93 ("srcu: Make rcutorture writer stalls print SRCU GP state")

This config has CONFIG_CLASSIC_SRCU=y and CONFIG_RCU_TORTURE_TEST=m, so
CONFIG_RCU_TORTURE_TEST is not defined - CONFIG_RCU_TORTURE_TEST_MODULE
is defined.  You probably want to protect srcutorture_get_gp_data() with
IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instead.

I have used the rcu tree from next-20170418 for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-03-08  1:16         ` Stephen Rothwell
  2017-03-08  1:37           ` Paul E. McKenney
@ 2017-03-08 18:05           ` Paul E. McKenney
  1 sibling, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-03-08 18:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul McKenney, David Miller, Networking, linux-next, LKML, Ursula Braun

On Wed, Mar 08, 2017 at 12:16:05PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 13 Feb 2017 17:43:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > I chickened out on that commit for this merge window, so it will come
> > > back at -rc1.  But I will cover that when I rebase to -rc1.  
> > 
> > OK, thanks.
> 
> [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"
> is needed again ... maybe time to rebase?

And I did rebase and push.  Passes light build testing, will be testing
more vigorously later today.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-03-08 10:13 ` Daniel Vetter
@ 2017-03-08 17:40   ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-03-08 17:40 UTC (permalink / raw)
  To: Stephen Rothwell, Intel Graphics, DRI, linux-next, linux-kernel,
	Chris Wilson

On Wed, Mar 08, 2017 at 11:13:38AM +0100, Daniel Vetter wrote:
> On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > In file included from include/linux/resource_ext.h:19:0,
> >                  from include/linux/pci.h:32,
> >                  from include/drm/drmP.h:50,
> >                  from drivers/gpu/drm/i915/i915_gem.c:28:
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device':
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function)
> >          SLAB_DESTROY_BY_RCU);
> >          ^
> > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
> >    (__flags), NULL)
> >     ^
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared identifier is reported only once for each function it appears in
> >          SLAB_DESTROY_BY_RCU);
> >          ^
> > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
> >    (__flags), NULL)
> >     ^
> > /
> > 
> > Caused by commit
> > 
> >   24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> 
> Awesome rename. Count us in among the people who first thought this
> provides more guarantees than it does.

Glad you like it!  ;-)

> > interacting with commit
> > 
> >   0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> > 
> > from the drm-intel tree.
> > 
> > I added the following merge fix patch:
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Wed, 8 Mar 2017 12:09:49 +1100
> > Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to
> >  SLAB_TYPESAFE_BY_RCU"
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> Should we handle this with a topic branch? It's trivial to resolve, but I
> fear the note that this conflict exists might get lost somewhere between
> now and when the drm pull lands in Linus' inbox in 2 months ...
> 
> Otoh he's probably going to compile test drm extra carefully and will
> notice :-)

If it gets too ugly, I can always allow both SLAB_TYPESAFE_BY_RCU
and SLAB_DESTROY_BY_RCU as synonyms in 4.12, and then remove
SLAB_DESTROY_BY_RCU in 4.13.

							Thanx, Paul

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > index 6a8258eacdcb..9f24c5da3f8d 100644
> > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > @@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void)
> >  	i915->requests = KMEM_CACHE(mock_request,
> >  				    SLAB_HWCACHE_ALIGN |
> >  				    SLAB_RECLAIM_ACCOUNT |
> > -				    SLAB_DESTROY_BY_RCU);
> > +				    SLAB_TYPESAFE_BY_RCU);
> >  	if (!i915->requests)
> >  		goto err_vmas;
> >  
> > -- 
> > 2.11.0
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-03-08  1:16 Stephen Rothwell
@ 2017-03-08 10:13 ` Daniel Vetter
  2017-03-08 17:40   ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Daniel Vetter @ 2017-03-08 10:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Vetter, Intel Graphics, linux-kernel, DRI, linux-next,
	Paul E. McKenney

On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from include/linux/resource_ext.h:19:0,
>                  from include/linux/pci.h:32,
>                  from include/drm/drmP.h:50,
>                  from drivers/gpu/drm/i915/i915_gem.c:28:
> drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device':
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function)
>          SLAB_DESTROY_BY_RCU);
>          ^
> include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
>    (__flags), NULL)
>     ^
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared identifier is reported only once for each function it appears in
>          SLAB_DESTROY_BY_RCU);
>          ^
> include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
>    (__flags), NULL)
>     ^
> /
> 
> Caused by commit
> 
>   24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

Awesome rename. Count us in among the people who first thought this
provides more guarantees than it does.

> interacting with commit
> 
>   0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> 
> from the drm-intel tree.
> 
> I added the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 8 Mar 2017 12:09:49 +1100
> Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to
>  SLAB_TYPESAFE_BY_RCU"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Should we handle this with a topic branch? It's trivial to resolve, but I
fear the note that this conflict exists might get lost somewhere between
now and when the drm pull lands in Linus' inbox in 2 months ...

Otoh he's probably going to compile test drm extra carefully and will
notice :-)
-Daniel

> ---
>  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 6a8258eacdcb..9f24c5da3f8d 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void)
>  	i915->requests = KMEM_CACHE(mock_request,
>  				    SLAB_HWCACHE_ALIGN |
>  				    SLAB_RECLAIM_ACCOUNT |
> -				    SLAB_DESTROY_BY_RCU);
> +				    SLAB_TYPESAFE_BY_RCU);
>  	if (!i915->requests)
>  		goto err_vmas;
>  
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-03-08  1:16         ` Stephen Rothwell
@ 2017-03-08  1:37           ` Paul E. McKenney
  2017-03-08 18:05           ` Paul E. McKenney
  1 sibling, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2017-03-08  1:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul McKenney, David Miller, Networking, linux-next, LKML, Ursula Braun

On Wed, Mar 08, 2017 at 12:16:05PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 13 Feb 2017 17:43:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > I chickened out on that commit for this merge window, so it will come
> > > back at -rc1.  But I will cover that when I rebase to -rc1.  
> > 
> > OK, thanks.
> 
> [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"
> is needed again ... maybe time to rebase?

On my list for tomorrow morning.  ;-)

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2017-03-08  1:16 Stephen Rothwell
  2017-03-08 10:13 ` Daniel Vetter
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-03-08  1:16 UTC (permalink / raw)
  To: Paul E. McKenney, Daniel Vetter, Intel Graphics, DRI
  Cc: linux-next, linux-kernel

Hi Paul,

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

In file included from include/linux/resource_ext.h:19:0,
                 from include/linux/pci.h:32,
                 from include/drm/drmP.h:50,
                 from drivers/gpu/drm/i915/i915_gem.c:28:
drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device':
drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function)
         SLAB_DESTROY_BY_RCU);
         ^
include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
   (__flags), NULL)
    ^
drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared identifier is reported only once for each function it appears in
         SLAB_DESTROY_BY_RCU);
         ^
include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
   (__flags), NULL)
    ^
/

Caused by commit

  24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")

from the drm-intel tree.

I added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 8 Mar 2017 12:09:49 +1100
Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to
 SLAB_TYPESAFE_BY_RCU"

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

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 6a8258eacdcb..9f24c5da3f8d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void)
 	i915->requests = KMEM_CACHE(mock_request,
 				    SLAB_HWCACHE_ALIGN |
 				    SLAB_RECLAIM_ACCOUNT |
-				    SLAB_DESTROY_BY_RCU);
+				    SLAB_TYPESAFE_BY_RCU);
 	if (!i915->requests)
 		goto err_vmas;
 
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-02-13  6:43       ` Stephen Rothwell
@ 2017-03-08  1:16         ` Stephen Rothwell
  2017-03-08  1:37           ` Paul E. McKenney
  2017-03-08 18:05           ` Paul E. McKenney
  0 siblings, 2 replies; 101+ messages in thread
From: Stephen Rothwell @ 2017-03-08  1:16 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Paul McKenney, David Miller, Networking, linux-next, LKML, Ursula Braun

Hi Paul,

On Mon, 13 Feb 2017 17:43:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > I chickened out on that commit for this merge window, so it will come
> > back at -rc1.  But I will cover that when I rebase to -rc1.  
> 
> OK, thanks.

[PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"
is needed again ... maybe time to rebase?

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-02-13  4:37     ` Paul E. McKenney
@ 2017-02-13  6:43       ` Stephen Rothwell
  2017-03-08  1:16         ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-02-13  6:43 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Paul McKenney, David Miller, Networking, linux-next, LKML, Ursula Braun

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> I chickened out on that commit for this merge window, so it will come
> back at -rc1.  But I will cover that when I rebase to -rc1.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-02-13  2:21   ` Stephen Rothwell
@ 2017-02-13  4:37     ` Paul E. McKenney
  2017-02-13  6:43       ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2017-02-13  4:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul McKenney, David Miller, Networking, linux-next, LKML, Ursula Braun

On Mon, Feb 13, 2017 at 01:21:33PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 19 Jan 2017 13:54:37 -0800 Paul McKenney <paulmckrcu@gmail.com> wrote:
> >
> > On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Hi Paul,
> > >
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a function)
> > >   .slab_flags = SLAB_DESTROY_BY_RCU,
> > >                 ^
> > >
> > > Caused by commit
> > >
> > >   c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> > >
> > > interacting with commit
> > >
> > >   ac7138746e14 ("smc: establish new socket family")
> > >
> > > from the net-next tree.
> > >
> > > I have applied the following merge fix patch (someone will need to
> > > remember to mention this to Linus):  
> > 
> > Thank you, Stephen!  I expect that there might be a bit more
> > bikeshedding on the name, but here is hoping...  :-/
> 
> The need for this merge fix patch has gone away today.  Is that a
> permanent situation, or will it come back?

I chickened out on that commit for this merge window, so it will come
back at -rc1.  But I will cover that when I rebase to -rc1.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-01-19 21:54 ` Paul McKenney
@ 2017-02-13  2:21   ` Stephen Rothwell
  2017-02-13  4:37     ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-02-13  2:21 UTC (permalink / raw)
  To: Paul McKenney
  Cc: Paul E. McKenney, David Miller, Networking, linux-next, LKML,
	Ursula Braun

Hi Paul,

On Thu, 19 Jan 2017 13:54:37 -0800 Paul McKenney <paulmckrcu@gmail.com> wrote:
>
> On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Paul,
> >
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a function)
> >   .slab_flags = SLAB_DESTROY_BY_RCU,
> >                 ^
> >
> > Caused by commit
> >
> >   c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> >
> > interacting with commit
> >
> >   ac7138746e14 ("smc: establish new socket family")
> >
> > from the net-next tree.
> >
> > I have applied the following merge fix patch (someone will need to
> > remember to mention this to Linus):  
> 
> Thank you, Stephen!  I expect that there might be a bit more
> bikeshedding on the name, but here is hoping...  :-/

The need for this merge fix patch has gone away today.  Is that a
permanent situation, or will it come back?
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2017-01-19  3:34 Stephen Rothwell
@ 2017-01-19 21:54 ` Paul McKenney
  2017-02-13  2:21   ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul McKenney @ 2017-01-19 21:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul E. McKenney, David Miller, Networking, linux-next, LKML,
	Ursula Braun

On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a function)
>   .slab_flags = SLAB_DESTROY_BY_RCU,
>                 ^
>
> Caused by commit
>
>   c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
>
> interacting with commit
>
>   ac7138746e14 ("smc: establish new socket family")
>
> from the net-next tree.
>
> I have applied the following merge fix patch (someone will need to
> remember to mention this to Linus):

Thank you, Stephen!  I expect that there might be a bit more
bikeshedding on the name, but here is hoping...  :-/

                                                      Thanx, Paul

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 19 Jan 2017 14:29:12 +1100
> Subject: [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  net/smc/af_smc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 4875e65f0c4a..a48260f9ebb7 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -99,7 +99,7 @@ struct proto smc_proto = {
>         .unhash         = smc_unhash_sk,
>         .obj_size       = sizeof(struct smc_sock),
>         .h.smc_hash     = &smc_v4_hashinfo,
> -       .slab_flags     = SLAB_DESTROY_BY_RCU,
> +       .slab_flags     = SLAB_TYPESAFE_BY_RCU,
>  };
>  EXPORT_SYMBOL_GPL(smc_proto);
>
> --
> 2.10.2
>
> --
> Cheers,
> Stephen Rothwell

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

* linux-next: build failure after merge of the rcu tree
@ 2017-01-19  3:34 Stephen Rothwell
  2017-01-19 21:54 ` Paul McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2017-01-19  3:34 UTC (permalink / raw)
  To: Paul E. McKenney, David Miller, Networking
  Cc: linux-next, linux-kernel, Ursula Braun

Hi Paul,

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

net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a function)
  .slab_flags = SLAB_DESTROY_BY_RCU,
                ^

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

I have applied the following merge fix patch (someone will need to
remember to mention this to Linus):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 19 Jan 2017 14:29:12 +1100
Subject: [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU"

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

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 4875e65f0c4a..a48260f9ebb7 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -99,7 +99,7 @@ struct proto smc_proto = {
 	.unhash		= smc_unhash_sk,
 	.obj_size	= sizeof(struct smc_sock),
 	.h.smc_hash	= &smc_v4_hashinfo,
-	.slab_flags	= SLAB_DESTROY_BY_RCU,
+	.slab_flags	= SLAB_TYPESAFE_BY_RCU,
 };
 EXPORT_SYMBOL_GPL(smc_proto);
 
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-05-02  4:37 Stephen Rothwell
@ 2016-05-02 11:06 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2016-05-02 11:06 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig

On Mon, May 02, 2016 at 02:37:36PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/kvm/vmx.c: In function 'vmx_init':
> arch/x86/kvm/vmx.c:11026:2: error: function '_r_a_p__v' is initialized like a variable
>   rcu_assign_pointer(crash_vmclear_loaded_vmcss,
>   ^
> In file included from include/linux/rbtree.h:34:0,
>                  from include/linux/mm_types.h:9,
>                  from arch/x86/kvm/irq.h:25,
>                  from arch/x86/kvm/vmx.c:19:
> include/linux/rcupdate.h:657:45: warning: the comparison will always evaluate as 'false' for the address of '_r_a_p__v' will never be NULL [-Waddress]
>   if (__builtin_constant_p(v) && (_r_a_p__v) == NULL) \
>                                              ^
> arch/x86/kvm/vmx.c:11026:2: note: in expansion of macro 'rcu_assign_pointer'
>   rcu_assign_pointer(crash_vmclear_loaded_vmcss,
>   ^
> include/linux/rcupdate.h:655:12: error: nested function '_r_a_p__v' declared but never defined  
>   typeof(v) _r_a_p__v = (v); \
>             ^
> arch/x86/kvm/vmx.c:11026:2: note: in expansion of macro 'rcu_assign_pointer'
>   rcu_assign_pointer(crash_vmclear_loaded_vmcss,
>   ^
> 
> Caused by commit
> 
>   16d7afcaa530 ("rcu: No ordering for rcu_assign_pointer() of NULL")
> 
> I have reverted that commit for today.

Too much fun when rcu_assign_pointer() is invoked on a pointer to a
function...  Sorry for the hassle!

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2016-05-02  4:37 Stephen Rothwell
  2016-05-02 11:06 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2016-05-02  4:37 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Paul,

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

arch/x86/kvm/vmx.c: In function 'vmx_init':
arch/x86/kvm/vmx.c:11026:2: error: function '_r_a_p__v' is initialized like a variable
  rcu_assign_pointer(crash_vmclear_loaded_vmcss,
  ^
In file included from include/linux/rbtree.h:34:0,
                 from include/linux/mm_types.h:9,
                 from arch/x86/kvm/irq.h:25,
                 from arch/x86/kvm/vmx.c:19:
include/linux/rcupdate.h:657:45: warning: the comparison will always evaluate as 'false' for the address of '_r_a_p__v' will never be NULL [-Waddress]
  if (__builtin_constant_p(v) && (_r_a_p__v) == NULL) \
                                             ^
arch/x86/kvm/vmx.c:11026:2: note: in expansion of macro 'rcu_assign_pointer'
  rcu_assign_pointer(crash_vmclear_loaded_vmcss,
  ^
include/linux/rcupdate.h:655:12: error: nested function '_r_a_p__v' declared but never defined  
  typeof(v) _r_a_p__v = (v); \
            ^
arch/x86/kvm/vmx.c:11026:2: note: in expansion of macro 'rcu_assign_pointer'
  rcu_assign_pointer(crash_vmclear_loaded_vmcss,
  ^

Caused by commit

  16d7afcaa530 ("rcu: No ordering for rcu_assign_pointer() of NULL")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-02-01  2:55 Stephen Rothwell
@ 2016-02-01  9:53 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2016-02-01  9:53 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Mon, Feb 01, 2016 at 01:55:51PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from /home/sfr/next/next/include/linux/spinlock_types.h:18:0,
>                  from /home/sfr/next/next/include/linux/spinlock.h:81,
>                  from /home/sfr/next/next/kernel/rcu/tree.c:33:
> /home/sfr/next/next/kernel/rcu/tree.c: In function 'rcu_init_one':
> /home/sfr/next/next/include/linux/lockdep.h:299:27: error: 'struct rt_mutex' has no member named 'dep_map'
>    lockdep_init_map(&(lock)->dep_map, name, key, 0)
>                            ^
> /home/sfr/next/next/kernel/rcu/tree.c:4572:4: note: in expansion of macro 'lockdep_set_class_and_name'
>     lockdep_set_class_and_name(&rnp->exp_funnel_mutex,
>     ^
> 
> Caused by commit
> 
>   725b7f3805c6 ("rcu: Convert expedited grace-period funnel lock to rt_mutex")
> 
> I have used the rcu tree from next-20160129 for today.

Apologies, that was too experimental for -next.  I have placed rcu/next
to precede the offending commit.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2016-02-01  2:55 Stephen Rothwell
  2016-02-01  9:53 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2016-02-01  2:55 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel

Hi Paul,

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

In file included from /home/sfr/next/next/include/linux/spinlock_types.h:18:0,
                 from /home/sfr/next/next/include/linux/spinlock.h:81,
                 from /home/sfr/next/next/kernel/rcu/tree.c:33:
/home/sfr/next/next/kernel/rcu/tree.c: In function 'rcu_init_one':
/home/sfr/next/next/include/linux/lockdep.h:299:27: error: 'struct rt_mutex' has no member named 'dep_map'
   lockdep_init_map(&(lock)->dep_map, name, key, 0)
                           ^
/home/sfr/next/next/kernel/rcu/tree.c:4572:4: note: in expansion of macro 'lockdep_set_class_and_name'
    lockdep_set_class_and_name(&rnp->exp_funnel_mutex,
    ^

Caused by commit

  725b7f3805c6 ("rcu: Convert expedited grace-period funnel lock to rt_mutex")

I have used the rcu tree from next-20160129 for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08 15:57                   ` Tejun Heo
@ 2016-01-08 16:18                     ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-08 16:18 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Boqun Feng, Stephen Rothwell, linux-next, linux-kernel,
	Christoph Lameter

On Fri, Jan 08, 2016 at 10:57:27AM -0500, Tejun Heo wrote:
> On Fri, Jan 08, 2016 at 07:53:41AM -0800, Paul E. McKenney wrote:
> > commit 61822ff81839ee3c5b6094ce348944d972b87892
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date:   Fri Jan 8 07:43:50 2016 -0800
> > 
> >     rcu: Document unique-name limitation for DEFINE_STATIC_SRCU()
> >     
> >     SRCU uses per-CPU variables, and DEFINE_STATIC_SRCU() uses a static
> >     per-CPU variable.  However, per-CPU variables have significant
> >     restrictions, for example, names of per-CPU variables must be globally
> >     unique, even if declared static.  These restrictions carry over to
> >     DEFINE_STATIC_SRCU(), and this commit therefore documents these
> >     restrictions.
> >     
> >     Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >     Reported-by: kbuild test robot <fengguang.wu@intel.com>
> >     Suggested-by: Boqun Feng <boqun.feng@gmail.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> > index f5f80c5643ac..dc8eb63c6568 100644
> > --- a/include/linux/srcu.h
> > +++ b/include/linux/srcu.h
> > @@ -99,8 +99,23 @@ void process_srcu(struct work_struct *work);
> >  	}
> >  
> >  /*
> > - * define and init a srcu struct at build time.
> > - * dont't call init_srcu_struct() nor cleanup_srcu_struct() on it.
> > + * Define and initialize a srcu struct at build time.
> > + * Do -not- call init_srcu_struct() nor cleanup_srcu_struct() on it.
> > + *
> > + * Note that although DEFINE_STATIC_SRCU() hides the name from other
> > + * files, the per-CPU variable rules nevertheless require that the
> > + * chosen name be globally unique.  These rules also prohibit use of
> > + * DEFINE_STATIC_SRCU() within a function.  If these rules are too
> > + * restrictive, declare the srcu_struct manually.  For example, in
> > + * each file:
> > + *
> > + *	static struct srcu_struct my_srcu;
> > + *
> > + * Then, before the first use of each my_srcu, manually initialize it:
> > + *
> > + *	init_srcu_struct(&my_srcu);
> > + *
> > + * See include/linux/percpu-defs.h for the rules on per-CPU variables.
> 
> FWIW,
> 
>  Reviewed-by: Tejun Heo <tj@kernel.org>

Applied, thank you!

> Thanks Stephen for posting the rules around static percpu definitions.

Me too!  Hey, it was building fine with all of my configurations,
so I was really beginning to wonder if this was some sort of early
April Fools joke.  ;-)

> I wonder whether there is a better way to tell people what's going on.

I hope so.  ;-)

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08 15:53                 ` Paul E. McKenney
  2016-01-08 15:57                   ` Tejun Heo
@ 2016-01-08 15:58                   ` Boqun Feng
  1 sibling, 0 replies; 101+ messages in thread
From: Boqun Feng @ 2016-01-08 15:58 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

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

On Fri, Jan 08, 2016 at 07:53:41AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 08, 2016 at 12:54:53PM +0800, Boqun Feng wrote:
> > On Thu, Jan 07, 2016 at 08:48:35PM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 08, 2016 at 03:08:50PM +1100, Stephen Rothwell wrote:
> > > > Hi Paul,
> > > > 
> > > > On Thu, 7 Jan 2016 19:41:57 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > > >
> > > > > Indeed, I suspect that SRCU might not be the only thing that would like
> > > > > static per-CPU variables.  ;-)
> > > > 
> > > > from include/linux/percpu-defs.h:
> > > > 
> > > >  * s390 and alpha modules require percpu variables to be defined as
> > > >  * weak to force the compiler to generate GOT based external
> > > >  * references for them.  This is necessary because percpu sections
> > > >  * will be located outside of the usually addressable area.
> > > >  *
> > > >  * This definition puts the following two extra restrictions when
> > > >  * defining percpu variables.
> > > >  *
> > > >  * 1. The symbol must be globally unique, even the static ones.
> > > >  * 2. Static percpu variables cannot be defined inside a function.
> > > >  *
> > > >  * Archs which need weak percpu definitions should define
> > > >  * ARCH_NEEDS_WEAK_PER_CPU in asm/percpu.h when necessary.
> > > >  *
> > > >  * To ensure that the generic code observes the above two
> > > >  * restrictions, if CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set weak
> > > >  * definition is used for all cases.
> > > > 
> > > > so they can be static, but must be globally unique.
> > 
> > Interesting ;-) Thank you.
> > 
> > > Thank you for the tutorial!  I have updated the patch to use a unique
> > > name for the srcu_struct added by rcuperf.c.
> > 
> > Plus a comment for DEFINE_STATIC_SRCU saying srcu can be defined as
> > static but must have a unique name for this reason?
> 
> Yes, plus some words about how to work around the limitation.  How about
> the patch below?
> 

Looks very good to me ;-)

Regards,
Boqun

> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 61822ff81839ee3c5b6094ce348944d972b87892
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Fri Jan 8 07:43:50 2016 -0800
> 
>     rcu: Document unique-name limitation for DEFINE_STATIC_SRCU()
>     
>     SRCU uses per-CPU variables, and DEFINE_STATIC_SRCU() uses a static
>     per-CPU variable.  However, per-CPU variables have significant
>     restrictions, for example, names of per-CPU variables must be globally
>     unique, even if declared static.  These restrictions carry over to
>     DEFINE_STATIC_SRCU(), and this commit therefore documents these
>     restrictions.
>     
>     Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>     Reported-by: kbuild test robot <fengguang.wu@intel.com>
>     Suggested-by: Boqun Feng <boqun.feng@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index f5f80c5643ac..dc8eb63c6568 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -99,8 +99,23 @@ void process_srcu(struct work_struct *work);
>  	}
>  
>  /*
> - * define and init a srcu struct at build time.
> - * dont't call init_srcu_struct() nor cleanup_srcu_struct() on it.
> + * Define and initialize a srcu struct at build time.
> + * Do -not- call init_srcu_struct() nor cleanup_srcu_struct() on it.
> + *
> + * Note that although DEFINE_STATIC_SRCU() hides the name from other
> + * files, the per-CPU variable rules nevertheless require that the
> + * chosen name be globally unique.  These rules also prohibit use of
> + * DEFINE_STATIC_SRCU() within a function.  If these rules are too
> + * restrictive, declare the srcu_struct manually.  For example, in
> + * each file:
> + *
> + *	static struct srcu_struct my_srcu;
> + *
> + * Then, before the first use of each my_srcu, manually initialize it:
> + *
> + *	init_srcu_struct(&my_srcu);
> + *
> + * See include/linux/percpu-defs.h for the rules on per-CPU variables.
>   */
>  #define __DEFINE_SRCU(name, is_static)					\
>  	static DEFINE_PER_CPU(struct srcu_struct_array, name##_srcu_array);\
> 

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08 15:53                 ` Paul E. McKenney
@ 2016-01-08 15:57                   ` Tejun Heo
  2016-01-08 16:18                     ` Paul E. McKenney
  2016-01-08 15:58                   ` Boqun Feng
  1 sibling, 1 reply; 101+ messages in thread
From: Tejun Heo @ 2016-01-08 15:57 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Boqun Feng, Stephen Rothwell, linux-next, linux-kernel,
	Christoph Lameter

On Fri, Jan 08, 2016 at 07:53:41AM -0800, Paul E. McKenney wrote:
> commit 61822ff81839ee3c5b6094ce348944d972b87892
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Fri Jan 8 07:43:50 2016 -0800
> 
>     rcu: Document unique-name limitation for DEFINE_STATIC_SRCU()
>     
>     SRCU uses per-CPU variables, and DEFINE_STATIC_SRCU() uses a static
>     per-CPU variable.  However, per-CPU variables have significant
>     restrictions, for example, names of per-CPU variables must be globally
>     unique, even if declared static.  These restrictions carry over to
>     DEFINE_STATIC_SRCU(), and this commit therefore documents these
>     restrictions.
>     
>     Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>     Reported-by: kbuild test robot <fengguang.wu@intel.com>
>     Suggested-by: Boqun Feng <boqun.feng@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index f5f80c5643ac..dc8eb63c6568 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -99,8 +99,23 @@ void process_srcu(struct work_struct *work);
>  	}
>  
>  /*
> - * define and init a srcu struct at build time.
> - * dont't call init_srcu_struct() nor cleanup_srcu_struct() on it.
> + * Define and initialize a srcu struct at build time.
> + * Do -not- call init_srcu_struct() nor cleanup_srcu_struct() on it.
> + *
> + * Note that although DEFINE_STATIC_SRCU() hides the name from other
> + * files, the per-CPU variable rules nevertheless require that the
> + * chosen name be globally unique.  These rules also prohibit use of
> + * DEFINE_STATIC_SRCU() within a function.  If these rules are too
> + * restrictive, declare the srcu_struct manually.  For example, in
> + * each file:
> + *
> + *	static struct srcu_struct my_srcu;
> + *
> + * Then, before the first use of each my_srcu, manually initialize it:
> + *
> + *	init_srcu_struct(&my_srcu);
> + *
> + * See include/linux/percpu-defs.h for the rules on per-CPU variables.

FWIW,

 Reviewed-by: Tejun Heo <tj@kernel.org>

Thanks Stephen for posting the rules around static percpu definitions.
I wonder whether there is a better way to tell people what's going on.

Thanks.

-- 
tejun

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  4:54               ` Boqun Feng
@ 2016-01-08 15:53                 ` Paul E. McKenney
  2016-01-08 15:57                   ` Tejun Heo
  2016-01-08 15:58                   ` Boqun Feng
  0 siblings, 2 replies; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-08 15:53 UTC (permalink / raw)
  To: Boqun Feng
  Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

On Fri, Jan 08, 2016 at 12:54:53PM +0800, Boqun Feng wrote:
> On Thu, Jan 07, 2016 at 08:48:35PM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 08, 2016 at 03:08:50PM +1100, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > On Thu, 7 Jan 2016 19:41:57 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > >
> > > > Indeed, I suspect that SRCU might not be the only thing that would like
> > > > static per-CPU variables.  ;-)
> > > 
> > > from include/linux/percpu-defs.h:
> > > 
> > >  * s390 and alpha modules require percpu variables to be defined as
> > >  * weak to force the compiler to generate GOT based external
> > >  * references for them.  This is necessary because percpu sections
> > >  * will be located outside of the usually addressable area.
> > >  *
> > >  * This definition puts the following two extra restrictions when
> > >  * defining percpu variables.
> > >  *
> > >  * 1. The symbol must be globally unique, even the static ones.
> > >  * 2. Static percpu variables cannot be defined inside a function.
> > >  *
> > >  * Archs which need weak percpu definitions should define
> > >  * ARCH_NEEDS_WEAK_PER_CPU in asm/percpu.h when necessary.
> > >  *
> > >  * To ensure that the generic code observes the above two
> > >  * restrictions, if CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set weak
> > >  * definition is used for all cases.
> > > 
> > > so they can be static, but must be globally unique.
> 
> Interesting ;-) Thank you.
> 
> > Thank you for the tutorial!  I have updated the patch to use a unique
> > name for the srcu_struct added by rcuperf.c.
> 
> Plus a comment for DEFINE_STATIC_SRCU saying srcu can be defined as
> static but must have a unique name for this reason?

Yes, plus some words about how to work around the limitation.  How about
the patch below?

							Thanx, Paul

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

commit 61822ff81839ee3c5b6094ce348944d972b87892
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Fri Jan 8 07:43:50 2016 -0800

    rcu: Document unique-name limitation for DEFINE_STATIC_SRCU()
    
    SRCU uses per-CPU variables, and DEFINE_STATIC_SRCU() uses a static
    per-CPU variable.  However, per-CPU variables have significant
    restrictions, for example, names of per-CPU variables must be globally
    unique, even if declared static.  These restrictions carry over to
    DEFINE_STATIC_SRCU(), and this commit therefore documents these
    restrictions.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Suggested-by: Boqun Feng <boqun.feng@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index f5f80c5643ac..dc8eb63c6568 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -99,8 +99,23 @@ void process_srcu(struct work_struct *work);
 	}
 
 /*
- * define and init a srcu struct at build time.
- * dont't call init_srcu_struct() nor cleanup_srcu_struct() on it.
+ * Define and initialize a srcu struct at build time.
+ * Do -not- call init_srcu_struct() nor cleanup_srcu_struct() on it.
+ *
+ * Note that although DEFINE_STATIC_SRCU() hides the name from other
+ * files, the per-CPU variable rules nevertheless require that the
+ * chosen name be globally unique.  These rules also prohibit use of
+ * DEFINE_STATIC_SRCU() within a function.  If these rules are too
+ * restrictive, declare the srcu_struct manually.  For example, in
+ * each file:
+ *
+ *	static struct srcu_struct my_srcu;
+ *
+ * Then, before the first use of each my_srcu, manually initialize it:
+ *
+ *	init_srcu_struct(&my_srcu);
+ *
+ * See include/linux/percpu-defs.h for the rules on per-CPU variables.
  */
 #define __DEFINE_SRCU(name, is_static)					\
 	static DEFINE_PER_CPU(struct srcu_struct_array, name##_srcu_array);\

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  4:48             ` Paul E. McKenney
@ 2016-01-08  4:54               ` Boqun Feng
  2016-01-08 15:53                 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Boqun Feng @ 2016-01-08  4:54 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

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

On Thu, Jan 07, 2016 at 08:48:35PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 08, 2016 at 03:08:50PM +1100, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > On Thu, 7 Jan 2016 19:41:57 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > Indeed, I suspect that SRCU might not be the only thing that would like
> > > static per-CPU variables.  ;-)
> > 
> > from include/linux/percpu-defs.h:
> > 
> >  * s390 and alpha modules require percpu variables to be defined as
> >  * weak to force the compiler to generate GOT based external
> >  * references for them.  This is necessary because percpu sections
> >  * will be located outside of the usually addressable area.
> >  *
> >  * This definition puts the following two extra restrictions when
> >  * defining percpu variables.
> >  *
> >  * 1. The symbol must be globally unique, even the static ones.
> >  * 2. Static percpu variables cannot be defined inside a function.
> >  *
> >  * Archs which need weak percpu definitions should define
> >  * ARCH_NEEDS_WEAK_PER_CPU in asm/percpu.h when necessary.
> >  *
> >  * To ensure that the generic code observes the above two
> >  * restrictions, if CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set weak
> >  * definition is used for all cases.
> > 
> > so they can be static, but must be globally unique.

Interesting ;-) Thank you.

> 
> Thank you for the tutorial!  I have updated the patch to use a unique
> name for the srcu_struct added by rcuperf.c.
> 

Plus a comment for DEFINE_STATIC_SRCU saying srcu can be defined as
static but must have a unique name for this reason?

Regards,
Boqun

> 							Thanx, Paul
> 

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  4:08           ` Stephen Rothwell
@ 2016-01-08  4:48             ` Paul E. McKenney
  2016-01-08  4:54               ` Boqun Feng
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-08  4:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Boqun Feng, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

On Fri, Jan 08, 2016 at 03:08:50PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 7 Jan 2016 19:41:57 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Indeed, I suspect that SRCU might not be the only thing that would like
> > static per-CPU variables.  ;-)
> 
> from include/linux/percpu-defs.h:
> 
>  * s390 and alpha modules require percpu variables to be defined as
>  * weak to force the compiler to generate GOT based external
>  * references for them.  This is necessary because percpu sections
>  * will be located outside of the usually addressable area.
>  *
>  * This definition puts the following two extra restrictions when
>  * defining percpu variables.
>  *
>  * 1. The symbol must be globally unique, even the static ones.
>  * 2. Static percpu variables cannot be defined inside a function.
>  *
>  * Archs which need weak percpu definitions should define
>  * ARCH_NEEDS_WEAK_PER_CPU in asm/percpu.h when necessary.
>  *
>  * To ensure that the generic code observes the above two
>  * restrictions, if CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set weak
>  * definition is used for all cases.
> 
> so they can be static, but must be globally unique.

Thank you for the tutorial!  I have updated the patch to use a unique
name for the srcu_struct added by rcuperf.c.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  1:37       ` Boqun Feng
  2016-01-08  3:41         ` Paul E. McKenney
@ 2016-01-08  4:10         ` Stephen Rothwell
  1 sibling, 0 replies; 101+ messages in thread
From: Stephen Rothwell @ 2016-01-08  4:10 UTC (permalink / raw)
  To: Boqun Feng
  Cc: Paul E. McKenney, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

Hi Boqun,

On Fri, 8 Jan 2016 09:37:04 +0800 Boqun Feng <boqun.feng@gmail.com> wrote:
>
> Mind to check your config options, Stephen?

This was an allyesconfig build, so I assume that
CONFIG_DEBUG_FORCE_WEAK_PER_CPU was set (sorry, I don;t have
the .config file at the moment).

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  3:41         ` Paul E. McKenney
@ 2016-01-08  4:08           ` Stephen Rothwell
  2016-01-08  4:48             ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2016-01-08  4:08 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Boqun Feng, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

Hi Paul,

On Thu, 7 Jan 2016 19:41:57 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Indeed, I suspect that SRCU might not be the only thing that would like
> static per-CPU variables.  ;-)

from include/linux/percpu-defs.h:

 * s390 and alpha modules require percpu variables to be defined as
 * weak to force the compiler to generate GOT based external
 * references for them.  This is necessary because percpu sections
 * will be located outside of the usually addressable area.
 *
 * This definition puts the following two extra restrictions when
 * defining percpu variables.
 *
 * 1. The symbol must be globally unique, even the static ones.
 * 2. Static percpu variables cannot be defined inside a function.
 *
 * Archs which need weak percpu definitions should define
 * ARCH_NEEDS_WEAK_PER_CPU in asm/percpu.h when necessary.
 *
 * To ensure that the generic code observes the above two
 * restrictions, if CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set weak
 * definition is used for all cases.

so they can be static, but must be globally unique.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-08  1:37       ` Boqun Feng
@ 2016-01-08  3:41         ` Paul E. McKenney
  2016-01-08  4:08           ` Stephen Rothwell
  2016-01-08  4:10         ` Stephen Rothwell
  1 sibling, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-08  3:41 UTC (permalink / raw)
  To: Boqun Feng
  Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

On Fri, Jan 08, 2016 at 09:37:04AM +0800, Boqun Feng wrote:
> On Thu, Jan 07, 2016 at 12:52:20PM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 08, 2016 at 07:19:32AM +1100, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > On Thu, 7 Jan 2016 10:02:44 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > >
> > > > On Thu, Jan 07, 2016 at 07:57:25PM +1100, Stephen Rothwell wrote:
> > > > > Hi Paul,
> > > > > 
> > > > > [I found this a few days ago, but I think I forgot to send the email,
> > > > > sorry.]
> > > > > 
> > > > > After merging the rcu tree, today's linux-next build (powerpc
> > > > > allyesconfig) failed like this:
> > > > > 
> > > > > kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
> > > > > kernel/rcu/rcutorture.o:(.discard+0x0): first defined here
> > > > > 
> > > > > Caused by commit
> > > > > 
> > > > >   abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")
> > > > > 
> > > > > I have reverted that commit for today.  
> > > > 
> > > > Hello, Stephen,
> > > > 
> > > > Very strange.  The "static" keyword does not mean anything here?
> > > > Easy enough to use different symbols in the two different files,
> > > > but this situation is not so good for information hiding.
> > > > 
> > > > Happy to update rcuperf.c to use a different name, but in the
> > > > immortal words of MSDOS, "Are you sure?" :-)
> > > 
> > > I have no idea why it happens, but I do get the error above unless I
> > > revert that commit.  So, yes, I am sure :-)
> > > 
> > > OK, I looked further and
> > > 
> > > DEFINE_STATIC_SRCU(srcu_ctl);
> > > 
> > > becomes this (NLs added for clarity):
> > > 
> > > static __attribute__((section(".discard"), unused)) char __pcpu_scope_srcu_ctl_srcu_array;
> > > extern __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> > > __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> > > extern __attribute__((section(".data..percpu" ""))) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> > > __attribute__((section(".data..percpu" ""))) __attribute__((weak)) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> > > static struct srcu_struct srcu_ctl = {
> > > 	.
> > > 	.
> > > };
> > > 
> > > So, the "static" is not very effective :-(
> > 
> > Oddly enough, this appears to be toolchain dependent.  No idea why.
> > 
> 
> Maybe the reason is because "static" doesn't work well with
> DEFINE_PER_CPU sometimes?
> 
> The definition of __DEFINE_STATIC_SRCU is:
> 
> #define __DEFINE_SRCU(name, is_static)					\
> 	static DEFINE_PER_CPU(struct srcu_struct_array, name##_srcu_array);\
> 	is_static struct srcu_struct name = __SRCU_STRUCT_INIT(name)
> 
> whereas DEFINE_PER_CPU(which calls DEFINE_PER_CPU_SECTION) *could*
> consists of *several* definitions:
> 
> #if defined(ARCH_NEEDS_WEAK_PER_CPU) || defined(CONFIG_DEBUG_FORCE_WEAK_PER_CPU)
> ...
> #define DEFINE_PER_CPU_SECTION(type, name, sec)				\
> 	__PCPU_DUMMY_ATTRS char __pcpu_scope_##name;			\
> 	extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name;		\
> 	__PCPU_DUMMY_ATTRS char __pcpu_unique_##name;			\
> 	extern __PCPU_ATTRS(sec) __typeof__(type) name;			\
> 	__PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES __weak			\
> 	__typeof__(type) name
> #else
> ...
> #define DEFINE_PER_CPU_SECTION(type, name, sec)				\
> 	__PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES			\
> 	__typeof__(type) name
> #endif
> 
> So if ARCH_NEEDS_WEAK_PER_CPU=y or CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y,
> the "static" keyword only has effects on the first definition i.e.
> __pcpu_scope_##name.
> 
> Mind to check your config options, Stephen?
> 
> 
> IOW, DEFINE_PER_CPU is not designed to work with "static", maybe we
> should add STATIC_DEFINE_PER_CPU for that purpose?

Indeed, I suspect that SRCU might not be the only thing that would like
static per-CPU variables.  ;-)

> Cc Tejun and Christoph for their opinions.
> 
> Regards,
> Boqun

							Thanx, Paul

> > Here is a patch that I will be merging in.
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > commit d81f900405de0dc6152692a2088258b8b35d740d
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date:   Thu Jan 7 12:39:10 2016 -0800
> > 
> >     Merge with abcd7ec0808e (rcutorture: Add RCU grace-period performance tests)
> >     
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index eef82a9460d8..4c8d99aa4f5e 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -188,8 +188,8 @@ static struct rcu_perf_ops rcu_bh_ops = {
> >   * Definitions for srcu perf testing.
> >   */
> >  
> > -DEFINE_STATIC_SRCU(srcu_ctl);
> > -static struct srcu_struct *srcu_ctlp = &srcu_ctl;
> > +DEFINE_STATIC_SRCU(srcu_ctl_perf);
> > +static struct srcu_struct *srcu_ctlp = &srcu_ctl_perf;
> >  
> >  static int srcu_perf_read_lock(void) __acquires(srcu_ctlp)
> >  {
> > 

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-07 20:52     ` Paul E. McKenney
@ 2016-01-08  1:37       ` Boqun Feng
  2016-01-08  3:41         ` Paul E. McKenney
  2016-01-08  4:10         ` Stephen Rothwell
  0 siblings, 2 replies; 101+ messages in thread
From: Boqun Feng @ 2016-01-08  1:37 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo, Christoph Lameter

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

On Thu, Jan 07, 2016 at 12:52:20PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 08, 2016 at 07:19:32AM +1100, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > On Thu, 7 Jan 2016 10:02:44 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > On Thu, Jan 07, 2016 at 07:57:25PM +1100, Stephen Rothwell wrote:
> > > > Hi Paul,
> > > > 
> > > > [I found this a few days ago, but I think I forgot to send the email,
> > > > sorry.]
> > > > 
> > > > After merging the rcu tree, today's linux-next build (powerpc
> > > > allyesconfig) failed like this:
> > > > 
> > > > kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
> > > > kernel/rcu/rcutorture.o:(.discard+0x0): first defined here
> > > > 
> > > > Caused by commit
> > > > 
> > > >   abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")
> > > > 
> > > > I have reverted that commit for today.  
> > > 
> > > Hello, Stephen,
> > > 
> > > Very strange.  The "static" keyword does not mean anything here?
> > > Easy enough to use different symbols in the two different files,
> > > but this situation is not so good for information hiding.
> > > 
> > > Happy to update rcuperf.c to use a different name, but in the
> > > immortal words of MSDOS, "Are you sure?" :-)
> > 
> > I have no idea why it happens, but I do get the error above unless I
> > revert that commit.  So, yes, I am sure :-)
> > 
> > OK, I looked further and
> > 
> > DEFINE_STATIC_SRCU(srcu_ctl);
> > 
> > becomes this (NLs added for clarity):
> > 
> > static __attribute__((section(".discard"), unused)) char __pcpu_scope_srcu_ctl_srcu_array;
> > extern __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> > __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> > extern __attribute__((section(".data..percpu" ""))) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> > __attribute__((section(".data..percpu" ""))) __attribute__((weak)) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> > static struct srcu_struct srcu_ctl = {
> > 	.
> > 	.
> > };
> > 
> > So, the "static" is not very effective :-(
> 
> Oddly enough, this appears to be toolchain dependent.  No idea why.
> 

Maybe the reason is because "static" doesn't work well with
DEFINE_PER_CPU sometimes?

The definition of __DEFINE_STATIC_SRCU is:

#define __DEFINE_SRCU(name, is_static)					\
	static DEFINE_PER_CPU(struct srcu_struct_array, name##_srcu_array);\
	is_static struct srcu_struct name = __SRCU_STRUCT_INIT(name)

whereas DEFINE_PER_CPU(which calls DEFINE_PER_CPU_SECTION) *could*
consists of *several* definitions:

#if defined(ARCH_NEEDS_WEAK_PER_CPU) || defined(CONFIG_DEBUG_FORCE_WEAK_PER_CPU)
...
#define DEFINE_PER_CPU_SECTION(type, name, sec)				\
	__PCPU_DUMMY_ATTRS char __pcpu_scope_##name;			\
	extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name;		\
	__PCPU_DUMMY_ATTRS char __pcpu_unique_##name;			\
	extern __PCPU_ATTRS(sec) __typeof__(type) name;			\
	__PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES __weak			\
	__typeof__(type) name
#else
...
#define DEFINE_PER_CPU_SECTION(type, name, sec)				\
	__PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES			\
	__typeof__(type) name
#endif

So if ARCH_NEEDS_WEAK_PER_CPU=y or CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y,
the "static" keyword only has effects on the first definition i.e.
__pcpu_scope_##name.

Mind to check your config options, Stephen?


IOW, DEFINE_PER_CPU is not designed to work with "static", maybe we
should add STATIC_DEFINE_PER_CPU for that purpose?

Cc Tejun and Christoph for their opinions.

Regards,
Boqun

> Here is a patch that I will be merging in.
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit d81f900405de0dc6152692a2088258b8b35d740d
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Thu Jan 7 12:39:10 2016 -0800
> 
>     Merge with abcd7ec0808e (rcutorture: Add RCU grace-period performance tests)
>     
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index eef82a9460d8..4c8d99aa4f5e 100644
> --- a/kernel/rcu/rcuperf.c
> +++ b/kernel/rcu/rcuperf.c
> @@ -188,8 +188,8 @@ static struct rcu_perf_ops rcu_bh_ops = {
>   * Definitions for srcu perf testing.
>   */
>  
> -DEFINE_STATIC_SRCU(srcu_ctl);
> -static struct srcu_struct *srcu_ctlp = &srcu_ctl;
> +DEFINE_STATIC_SRCU(srcu_ctl_perf);
> +static struct srcu_struct *srcu_ctlp = &srcu_ctl_perf;
>  
>  static int srcu_perf_read_lock(void) __acquires(srcu_ctlp)
>  {
> 

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-07 20:19   ` Stephen Rothwell
@ 2016-01-07 20:52     ` Paul E. McKenney
  2016-01-08  1:37       ` Boqun Feng
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-07 20:52 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Fri, Jan 08, 2016 at 07:19:32AM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 7 Jan 2016 10:02:44 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Thu, Jan 07, 2016 at 07:57:25PM +1100, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > [I found this a few days ago, but I think I forgot to send the email,
> > > sorry.]
> > > 
> > > After merging the rcu tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > > 
> > > kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
> > > kernel/rcu/rcutorture.o:(.discard+0x0): first defined here
> > > 
> > > Caused by commit
> > > 
> > >   abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")
> > > 
> > > I have reverted that commit for today.  
> > 
> > Hello, Stephen,
> > 
> > Very strange.  The "static" keyword does not mean anything here?
> > Easy enough to use different symbols in the two different files,
> > but this situation is not so good for information hiding.
> > 
> > Happy to update rcuperf.c to use a different name, but in the
> > immortal words of MSDOS, "Are you sure?" :-)
> 
> I have no idea why it happens, but I do get the error above unless I
> revert that commit.  So, yes, I am sure :-)
> 
> OK, I looked further and
> 
> DEFINE_STATIC_SRCU(srcu_ctl);
> 
> becomes this (NLs added for clarity):
> 
> static __attribute__((section(".discard"), unused)) char __pcpu_scope_srcu_ctl_srcu_array;
> extern __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
> extern __attribute__((section(".data..percpu" ""))) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> __attribute__((section(".data..percpu" ""))) __attribute__((weak)) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
> static struct srcu_struct srcu_ctl = {
> 	.
> 	.
> };
> 
> So, the "static" is not very effective :-(

Oddly enough, this appears to be toolchain dependent.  No idea why.

Here is a patch that I will be merging in.

							Thanx, Paul

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

commit d81f900405de0dc6152692a2088258b8b35d740d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Thu Jan 7 12:39:10 2016 -0800

    Merge with abcd7ec0808e (rcutorture: Add RCU grace-period performance tests)
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index eef82a9460d8..4c8d99aa4f5e 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -188,8 +188,8 @@ static struct rcu_perf_ops rcu_bh_ops = {
  * Definitions for srcu perf testing.
  */
 
-DEFINE_STATIC_SRCU(srcu_ctl);
-static struct srcu_struct *srcu_ctlp = &srcu_ctl;
+DEFINE_STATIC_SRCU(srcu_ctl_perf);
+static struct srcu_struct *srcu_ctlp = &srcu_ctl_perf;
 
 static int srcu_perf_read_lock(void) __acquires(srcu_ctlp)
 {

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-07 18:02 ` Paul E. McKenney
@ 2016-01-07 20:19   ` Stephen Rothwell
  2016-01-07 20:52     ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2016-01-07 20:19 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel

Hi Paul,

On Thu, 7 Jan 2016 10:02:44 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Thu, Jan 07, 2016 at 07:57:25PM +1100, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > [I found this a few days ago, but I think I forgot to send the email,
> > sorry.]
> > 
> > After merging the rcu tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
> > kernel/rcu/rcutorture.o:(.discard+0x0): first defined here
> > 
> > Caused by commit
> > 
> >   abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")
> > 
> > I have reverted that commit for today.  
> 
> Hello, Stephen,
> 
> Very strange.  The "static" keyword does not mean anything here?
> Easy enough to use different symbols in the two different files,
> but this situation is not so good for information hiding.
> 
> Happy to update rcuperf.c to use a different name, but in the
> immortal words of MSDOS, "Are you sure?" :-)

I have no idea why it happens, but I do get the error above unless I
revert that commit.  So, yes, I am sure :-)

OK, I looked further and

DEFINE_STATIC_SRCU(srcu_ctl);

becomes this (NLs added for clarity):

static __attribute__((section(".discard"), unused)) char __pcpu_scope_srcu_ctl_srcu_array;
extern __attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
__attribute__((section(".discard"), unused)) char __pcpu_unique_srcu_ctl_srcu_array;
extern __attribute__((section(".data..percpu" ""))) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
__attribute__((section(".data..percpu" ""))) __attribute__((weak)) __typeof__(struct srcu_struct_array) srcu_ctl_srcu_array;
static struct srcu_struct srcu_ctl = {
	.
	.
};

So, the "static" is not very effective :-(

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2016-01-07  8:57 Stephen Rothwell
@ 2016-01-07 18:02 ` Paul E. McKenney
  2016-01-07 20:19   ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2016-01-07 18:02 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Thu, Jan 07, 2016 at 07:57:25PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> [I found this a few days ago, but I think I forgot to send the email,
> sorry.]
> 
> After merging the rcu tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
> kernel/rcu/rcutorture.o:(.discard+0x0): first defined here
> 
> Caused by commit
> 
>   abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")
> 
> I have reverted that commit for today.

Hello, Stephen,

Very strange.  The "static" keyword does not mean anything here?
Easy enough to use different symbols in the two different files,
but this situation is not so good for information hiding.

Happy to update rcuperf.c to use a different name, but in the
immortal words of MSDOS, "Are you sure?" :-)

						Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2016-01-07  8:57 Stephen Rothwell
  2016-01-07 18:02 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2016-01-07  8:57 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel

Hi Paul,

[I found this a few days ago, but I think I forgot to send the email,
sorry.]

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

kernel/rcu/rcuperf.o:(.discard+0x0): multiple definition of `__pcpu_unique_srcu_ctl_srcu_array'
kernel/rcu/rcutorture.o:(.discard+0x0): first defined here

Caused by commit

  abcd7ec0808e ("rcutorture: Add RCU grace-period performance tests")

I have reverted that commit for today.

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-02  7:29           ` Ingo Molnar
@ 2015-09-02  8:34             ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2015-09-02  8:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Davidlohr Bueso, Stephen Rothwell, linux-next, linux-kernel, peterz

On Wed, Sep 02, 2015 at 09:29:18AM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > On Tue, Sep 01, 2015 at 11:40:51PM -0700, Davidlohr Bueso wrote:
> > > On Tue, 2015-09-01 at 22:26 -0700, Paul E. McKenney wrote:
> > > > Davidlohr, the error is due to sched_setscheduler_nocheck() not being
> > > > exported, so that Stephen gets this failure when building modules.
> > > > This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.
> > > > 
> > > > Thoughts?
> > > 
> > > Right, the below should take care of it. Although I think it makes sense
> > > to get this into at least 4.3 even if we won't use it until 4.4. Simply
> > > because we already export sched_setscheduler(). If you agree I guess we
> > > could route via -tip.
> > 
> > Given an ack from Peter or Ingo, I would happy to queue it.  But we are
> > talking 4.4 rather than 4.3, sorry!
> 
> The export looks good to me:
> 
> Acked-by: Ingo Molnar <mingo@kernel.org>

Very good, queued for 4.4!

							Thanx, Paul

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

sched: Export sched_setscheduler_nocheck

The new locktorture rtmutex_lock tests exercise priority boosting, which
means that they need to set some tasks to real-time priority.  To do this,
they use sched_setscheduler_nocheck().  However, this is not exported to
modules, which results in the following error when building locktorture
as a module:

ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!

This commit therefore adds an EXPORT_SYMBOL_GPL() to allow this function
to be invoked from locktorture when built as a module.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Ingo Molnar <mingo@kernel.org>

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5e73c79fadd0..5eee11b2b4b0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3960,6 +3960,7 @@ int sched_setscheduler_nocheck(struct task_struct *p, int policy,
 {
 	return _sched_setscheduler(p, policy, param, false);
 }
+EXPORT_SYMBOL_GPL(sched_setscheduler_nocheck);
 
 static int
 do_sched_setscheduler(pid_t pid, int policy, struct sched_param __user *param)

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-02  7:14         ` Paul E. McKenney
@ 2015-09-02  7:29           ` Ingo Molnar
  2015-09-02  8:34             ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Ingo Molnar @ 2015-09-02  7:29 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Davidlohr Bueso, Stephen Rothwell, linux-next, linux-kernel, peterz


* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> On Tue, Sep 01, 2015 at 11:40:51PM -0700, Davidlohr Bueso wrote:
> > On Tue, 2015-09-01 at 22:26 -0700, Paul E. McKenney wrote:
> > > Davidlohr, the error is due to sched_setscheduler_nocheck() not being
> > > exported, so that Stephen gets this failure when building modules.
> > > This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.
> > > 
> > > Thoughts?
> > 
> > Right, the below should take care of it. Although I think it makes sense
> > to get this into at least 4.3 even if we won't use it until 4.4. Simply
> > because we already export sched_setscheduler(). If you agree I guess we
> > could route via -tip.
> 
> Given an ack from Peter or Ingo, I would happy to queue it.  But we are
> talking 4.4 rather than 4.3, sorry!

The export looks good to me:

Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-02  6:40       ` Davidlohr Bueso
@ 2015-09-02  7:14         ` Paul E. McKenney
  2015-09-02  7:29           ` Ingo Molnar
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-09-02  7:14 UTC (permalink / raw)
  To: Davidlohr Bueso
  Cc: Stephen Rothwell, linux-next, linux-kernel, Ingo Molnar, peterz

On Tue, Sep 01, 2015 at 11:40:51PM -0700, Davidlohr Bueso wrote:
> On Tue, 2015-09-01 at 22:26 -0700, Paul E. McKenney wrote:
> > Davidlohr, the error is due to sched_setscheduler_nocheck() not being
> > exported, so that Stephen gets this failure when building modules.
> > This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.
> > 
> > Thoughts?
> 
> Right, the below should take care of it. Although I think it makes sense
> to get this into at least 4.3 even if we won't use it until 4.4. Simply
> because we already export sched_setscheduler(). If you agree I guess we
> could route via -tip.

Given an ack from Peter or Ingo, I would happy to queue it.  But we are
talking 4.4 rather than 4.3, sorry!

							Thanx, Paul

> Thanks,
> Davidlohr
> 
> ----8<------------------------------------
> Subject: [PATCH -next] sched: Export sched_setscheduler_nocheck
> 
> ... just like regular sched_setscheduler(). We need this, for locktorture
> otherwise we can fail to build modules, ie:
> 
> ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Ingo Molnar <mingo@kernel.org>
> ---
>  kernel/sched/core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3595403..7b51f64 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4012,6 +4012,7 @@ int sched_setscheduler_nocheck(struct task_struct *p, int policy,
>  {
>  	return _sched_setscheduler(p, policy, param, false);
>  }
> +EXPORT_SYMBOL_GPL(sched_setscheduler_nocheck);
> 
>  static int
>  do_sched_setscheduler(pid_t pid, int policy, struct sched_param __user *param)
> -- 
> 2.1.4
> 
> 
> 

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-02  5:26     ` Paul E. McKenney
@ 2015-09-02  6:40       ` Davidlohr Bueso
  2015-09-02  7:14         ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Davidlohr Bueso @ 2015-09-02  6:40 UTC (permalink / raw)
  To: paulmck; +Cc: Stephen Rothwell, linux-next, linux-kernel, Ingo Molnar

On Tue, 2015-09-01 at 22:26 -0700, Paul E. McKenney wrote:
> Davidlohr, the error is due to sched_setscheduler_nocheck() not being
> exported, so that Stephen gets this failure when building modules.
> This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.
> 
> Thoughts?

Right, the below should take care of it. Although I think it makes sense
to get this into at least 4.3 even if we won't use it until 4.4. Simply
because we already export sched_setscheduler(). If you agree I guess we
could route via -tip.

Thanks,
Davidlohr

----8<------------------------------------
Subject: [PATCH -next] sched: Export sched_setscheduler_nocheck

... just like regular sched_setscheduler(). We need this, for locktorture
otherwise we can fail to build modules, ie:

ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3595403..7b51f64 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4012,6 +4012,7 @@ int sched_setscheduler_nocheck(struct task_struct *p, int policy,
 {
 	return _sched_setscheduler(p, policy, param, false);
 }
+EXPORT_SYMBOL_GPL(sched_setscheduler_nocheck);
 
 static int
 do_sched_setscheduler(pid_t pid, int policy, struct sched_param __user *param)
-- 
2.1.4

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-02  3:58   ` Stephen Rothwell
@ 2015-09-02  5:26     ` Paul E. McKenney
  2015-09-02  6:40       ` Davidlohr Bueso
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-09-02  5:26 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Davidlohr Bueso

On Wed, Sep 02, 2015 at 01:58:00PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Tue, Sep 01, 2015 at 01:50:06PM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!
> > > 
> > > Caused by commits
> > > 
> > >   04be76a9b067 ("locktorture: Support rtmutex torturing")
> > >   40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")
> > > 
> > > and maybe more.
> > > 
> > > I have used the rcu tree from next-20150831 for today.
> > 
> > It is looking like I will be deferring these to v4.4, apologies for
> > the hassle!
> 
> This still fails to build but now I only get the error about
> sched_setscheduler_nocheck.

OK, now I actually have deferred these to v4.4.

Davidlohr, the error is due to sched_setscheduler_nocheck() not being
exported, so that Stephen gets this failure when building modules.
This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.

Thoughts?

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-01  7:49 ` Paul E. McKenney
@ 2015-09-02  3:58   ` Stephen Rothwell
  2015-09-02  5:26     ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2015-09-02  3:58 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Davidlohr Bueso

Hi Paul,

On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Tue, Sep 01, 2015 at 01:50:06PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!
> > 
> > Caused by commits
> > 
> >   04be76a9b067 ("locktorture: Support rtmutex torturing")
> >   40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")
> > 
> > and maybe more.
> > 
> > I have used the rcu tree from next-20150831 for today.
> 
> It is looking like I will be deferring these to v4.4, apologies for
> the hassle!

This still fails to build but now I only get the error about
sched_setscheduler_nocheck.

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-09-01  3:50 Stephen Rothwell
@ 2015-09-01  7:49 ` Paul E. McKenney
  2015-09-02  3:58   ` Stephen Rothwell
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-09-01  7:49 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Davidlohr Bueso

On Tue, Sep 01, 2015 at 01:50:06PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!
> ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
> ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
> ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
> ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
> ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!
> 
> Caused by commits
> 
>   04be76a9b067 ("locktorture: Support rtmutex torturing")
>   40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")
> 
> and maybe more.
> 
> I have used the rcu tree from next-20150831 for today.

It is looking like I will be deferring these to v4.4, apologies for
the hassle!

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2015-09-01  3:50 Stephen Rothwell
  2015-09-01  7:49 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2015-09-01  3:50 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Davidlohr Bueso

Hi Paul,

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

ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko] undefined!
ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!

Caused by commits

  04be76a9b067 ("locktorture: Support rtmutex torturing")
  40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")

and maybe more.

I have used the rcu tree from next-20150831 for today.

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-17 21:33           ` Paul E. McKenney
@ 2015-07-18  2:40             ` Ingo Molnar
  0 siblings, 0 replies; 101+ messages in thread
From: Ingo Molnar @ 2015-07-18  2:40 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski


* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > > And here is a prototype patch, which I intend to merge with the existing patch 
> > > that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  I will also queue a 
> > > revert of the patch below for 4.4.
> > > 
> > > Thoughts?
> > > 
> > > 							Thanx, Paul
> > > 
> > > ------------------------------------------------------------------------
> > > 
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 41c49b12fe6d..663d6e028c3d 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void)
> > >  
> > >  #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > >  
> > > +/* Deprecate the rcu_lockdep_assert() macro. */
> > > +static inline void __attribute((deprecated)) deprecate_rcu_lockdep_assert(void)
> > > +{
> > > +}
> > > +
> > >  #ifdef CONFIG_PROVE_RCU
> > >  
> > >  /**
> > > + * rcu_lockdep_assert - emit lockdep splat if specified condition not met
> > > + * @c: condition to check
> > > + * @s: informative message
> > > + */
> > > +#define rcu_lockdep_assert(c, s)					\
> > > +	do {								\
> > > +		static bool __section(.data.unlikely) __warned;		\
> > > +		deprecate_rcu_lockdep_assert();				\
> > > +		if (debug_lockdep_rcu_enabled() && !__warned && !(c)) {	\
> > > +			__warned = true;				\
> > > +			lockdep_rcu_suspicious(__FILE__, __LINE__, s);	\
> > > +		}							\
> > 
> > Btw., out of general macro paranoia I'd write such constructs as something like:
> > 
> > 		if (!(c) && debug_lockdep_rcu_enabled() && !__warned) {	\
> > 
> > I.e. always evaluate 'c' even if debugging is off. This way if the construct is 
> > fed an expression with a side effect (bad idea!) then it still works regardless of 
> > whether the warning triggered already or not.
> 
> If you feel strongly about this, I will need to make lockdep_is_held()
> be defined when lockdep is disabled. [...]

No need - if it goes deeper then I wouldn't worry.

Thanks,

	Ingo

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-17 19:51         ` Ingo Molnar
@ 2015-07-17 21:33           ` Paul E. McKenney
  2015-07-18  2:40             ` Ingo Molnar
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-07-17 21:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski

On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > And here is a prototype patch, which I intend to merge with the existing patch 
> > that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  I will also queue a 
> > revert of the patch below for 4.4.
> > 
> > Thoughts?
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 41c49b12fe6d..663d6e028c3d 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void)
> >  
> >  #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >  
> > +/* Deprecate the rcu_lockdep_assert() macro. */
> > +static inline void __attribute((deprecated)) deprecate_rcu_lockdep_assert(void)
> > +{
> > +}
> > +
> >  #ifdef CONFIG_PROVE_RCU
> >  
> >  /**
> > + * rcu_lockdep_assert - emit lockdep splat if specified condition not met
> > + * @c: condition to check
> > + * @s: informative message
> > + */
> > +#define rcu_lockdep_assert(c, s)					\
> > +	do {								\
> > +		static bool __section(.data.unlikely) __warned;		\
> > +		deprecate_rcu_lockdep_assert();				\
> > +		if (debug_lockdep_rcu_enabled() && !__warned && !(c)) {	\
> > +			__warned = true;				\
> > +			lockdep_rcu_suspicious(__FILE__, __LINE__, s);	\
> > +		}							\
> 
> Btw., out of general macro paranoia I'd write such constructs as something like:
> 
> 		if (!(c) && debug_lockdep_rcu_enabled() && !__warned) {	\
> 
> I.e. always evaluate 'c' even if debugging is off. This way if the construct is 
> fed an expression with a side effect (bad idea!) then it still works regardless of 
> whether the warning triggered already or not.

If you feel strongly about this, I will need to make lockdep_is_held()
be defined when lockdep is disabled.  Easy enough to do, just thought
I should double-check.

> But this construct is OK too to me, so feel free to add my:
> 
>   Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thank you!

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-17 18:53       ` Paul E. McKenney
@ 2015-07-17 19:51         ` Ingo Molnar
  2015-07-17 21:33           ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Ingo Molnar @ 2015-07-17 19:51 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski


* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> And here is a prototype patch, which I intend to merge with the existing patch 
> that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  I will also queue a 
> revert of the patch below for 4.4.
> 
> Thoughts?
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 41c49b12fe6d..663d6e028c3d 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void)
>  
>  #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
>  
> +/* Deprecate the rcu_lockdep_assert() macro. */
> +static inline void __attribute((deprecated)) deprecate_rcu_lockdep_assert(void)
> +{
> +}
> +
>  #ifdef CONFIG_PROVE_RCU
>  
>  /**
> + * rcu_lockdep_assert - emit lockdep splat if specified condition not met
> + * @c: condition to check
> + * @s: informative message
> + */
> +#define rcu_lockdep_assert(c, s)					\
> +	do {								\
> +		static bool __section(.data.unlikely) __warned;		\
> +		deprecate_rcu_lockdep_assert();				\
> +		if (debug_lockdep_rcu_enabled() && !__warned && !(c)) {	\
> +			__warned = true;				\
> +			lockdep_rcu_suspicious(__FILE__, __LINE__, s);	\
> +		}							\

Btw., out of general macro paranoia I'd write such constructs as something like:

		if (!(c) && debug_lockdep_rcu_enabled() && !__warned) {	\

I.e. always evaluate 'c' even if debugging is off. This way if the construct is 
fed an expression with a side effect (bad idea!) then it still works regardless of 
whether the warning triggered already or not.

But this construct is OK too to me, so feel free to add my:

  Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-17 17:35     ` Paul E. McKenney
@ 2015-07-17 18:53       ` Paul E. McKenney
  2015-07-17 19:51         ` Ingo Molnar
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-07-17 18:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski

On Fri, Jul 17, 2015 at 10:35:28AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 17, 2015 at 01:40:46PM +0200, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > > On Thu, Jul 16, 2015 at 01:14:23PM +1000, Stephen Rothwell wrote:
> > > > Hi Paul,
> > > > 
> > > > After merging the rcu tree, today's linux-next build (arm
> > > > multi_v7_defconfig) failed like this:
> > > > 
> > > > kernel/notifier.c: In function 'notify_die':
> > > > kernel/notifier.c:547:2: error: implicit declaration of function 'rcu_lockdep_assert' [-Werror=implicit-function-declaration]
> > > >   rcu_lockdep_assert(rcu_is_watching(),
> > > >   ^
> > > > 
> > > > Caused by commit
> > > > 
> > > >   02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > > > 
> > > > interacting with commit
> > > > 
> > > >   e727c7d7a11e ("notifiers, RCU: Assert that RCU is watching in notify_die()")
> > > > 
> > > > [ and I also noted
> > > >   0333a209cbf6 ("x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion")
> > > > ]
> > > > 
> > > > from the tip tree.
> > > 
> > > Thank you in both cases!  I suspect that more will follow, so is there
> > > something I can do to make this easier?  (Hard for me to patch stuff
> > > that is not yet in the tree...)
> > 
> > So we could keep the old macro around as well for such cases, and then remove it 
> > in v4.4 or so?
> 
> Works for me!  Will do.

And here is a prototype patch, which I intend to merge with the existing
patch that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  I will
also queue a revert of the patch below for 4.4.

Thoughts?

							Thanx, Paul

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

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 41c49b12fe6d..663d6e028c3d 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void)
 
 #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
 
+/* Deprecate the rcu_lockdep_assert() macro. */
+static inline void __attribute((deprecated)) deprecate_rcu_lockdep_assert(void)
+{
+}
+
 #ifdef CONFIG_PROVE_RCU
 
 /**
+ * rcu_lockdep_assert - emit lockdep splat if specified condition not met
+ * @c: condition to check
+ * @s: informative message
+ */
+#define rcu_lockdep_assert(c, s)					\
+	do {								\
+		static bool __section(.data.unlikely) __warned;		\
+		deprecate_rcu_lockdep_assert();				\
+		if (debug_lockdep_rcu_enabled() && !__warned && !(c)) {	\
+			__warned = true;				\
+			lockdep_rcu_suspicious(__FILE__, __LINE__, s);	\
+		}							\
+	} while (0)
+
+/**
  * RCU_LOCKDEP_WARN - emit lockdep splat if specified condition is met
  * @c: condition to check
  * @s: informative message
@@ -575,6 +595,7 @@ static inline void rcu_preempt_sleep_check(void)
 
 #else /* #ifdef CONFIG_PROVE_RCU */
 
+#define rcu_lockdep_assert(c, s) deprecate_rcu_lockdep_assert()
 #define RCU_LOCKDEP_WARN(c, s) do { } while (0)
 #define rcu_sleep_check() do { } while (0)
 

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-17 11:40   ` Ingo Molnar
@ 2015-07-17 17:35     ` Paul E. McKenney
  2015-07-17 18:53       ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2015-07-17 17:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski

On Fri, Jul 17, 2015 at 01:40:46PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > On Thu, Jul 16, 2015 at 01:14:23PM +1000, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > After merging the rcu tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > > 
> > > kernel/notifier.c: In function 'notify_die':
> > > kernel/notifier.c:547:2: error: implicit declaration of function 'rcu_lockdep_assert' [-Werror=implicit-function-declaration]
> > >   rcu_lockdep_assert(rcu_is_watching(),
> > >   ^
> > > 
> > > Caused by commit
> > > 
> > >   02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > > 
> > > interacting with commit
> > > 
> > >   e727c7d7a11e ("notifiers, RCU: Assert that RCU is watching in notify_die()")
> > > 
> > > [ and I also noted
> > >   0333a209cbf6 ("x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion")
> > > ]
> > > 
> > > from the tip tree.
> > 
> > Thank you in both cases!  I suspect that more will follow, so is there
> > something I can do to make this easier?  (Hard for me to patch stuff
> > that is not yet in the tree...)
> 
> So we could keep the old macro around as well for such cases, and then remove it 
> in v4.4 or so?

Works for me!  Will do.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-16  3:51 ` Paul E. McKenney
  2015-07-16  5:50   ` Stephen Rothwell
@ 2015-07-17 11:40   ` Ingo Molnar
  2015-07-17 17:35     ` Paul E. McKenney
  1 sibling, 1 reply; 101+ messages in thread
From: Ingo Molnar @ 2015-07-17 11:40 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski


* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> On Thu, Jul 16, 2015 at 01:14:23PM +1000, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > After merging the rcu tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > kernel/notifier.c: In function 'notify_die':
> > kernel/notifier.c:547:2: error: implicit declaration of function 'rcu_lockdep_assert' [-Werror=implicit-function-declaration]
> >   rcu_lockdep_assert(rcu_is_watching(),
> >   ^
> > 
> > Caused by commit
> > 
> >   02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > 
> > interacting with commit
> > 
> >   e727c7d7a11e ("notifiers, RCU: Assert that RCU is watching in notify_die()")
> > 
> > [ and I also noted
> >   0333a209cbf6 ("x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion")
> > ]
> > 
> > from the tip tree.
> 
> Thank you in both cases!  I suspect that more will follow, so is there
> something I can do to make this easier?  (Hard for me to patch stuff
> that is not yet in the tree...)

So we could keep the old macro around as well for such cases, and then remove it 
in v4.4 or so?

Thanks,

	Ingo

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-16  3:51 ` Paul E. McKenney
@ 2015-07-16  5:50   ` Stephen Rothwell
  2015-07-17 11:40   ` Ingo Molnar
  1 sibling, 0 replies; 101+ messages in thread
From: Stephen Rothwell @ 2015-07-16  5:50 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andy Lutomirski

Hi Paul,

On Wed, 15 Jul 2015 20:51:38 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> Thank you in both cases!  I suspect that more will follow, so is there
> something I can do to make this easier?  (Hard for me to patch stuff
> that is not yet in the tree...)

No, that is what I am here for.  But it would be good if you remember
this when it comes time for your tree to be merged into tip ...

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-07-16  3:14 Stephen Rothwell
@ 2015-07-16  3:51 ` Paul E. McKenney
  2015-07-16  5:50   ` Stephen Rothwell
  2015-07-17 11:40   ` Ingo Molnar
  0 siblings, 2 replies; 101+ messages in thread
From: Paul E. McKenney @ 2015-07-16  3:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andy Lutomirski

On Thu, Jul 16, 2015 at 01:14:23PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/notifier.c: In function 'notify_die':
> kernel/notifier.c:547:2: error: implicit declaration of function 'rcu_lockdep_assert' [-Werror=implicit-function-declaration]
>   rcu_lockdep_assert(rcu_is_watching(),
>   ^
> 
> Caused by commit
> 
>   02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> 
> interacting with commit
> 
>   e727c7d7a11e ("notifiers, RCU: Assert that RCU is watching in notify_die()")
> 
> [ and I also noted
>   0333a209cbf6 ("x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion")
> ]
> 
> from the tip tree.

Thank you in both cases!  I suspect that more will follow, so is there
something I can do to make this easier?  (Hard for me to patch stuff
that is not yet in the tree...)

							Thanx, Paul

> I added the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 16 Jul 2015 13:08:50 +1000
> Subject: [PATCH] rcu: merge fix for Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/irq.c | 2 +-
>  kernel/notifier.c     | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> index 30dbf35bc90b..f9cd81825187 100644
> --- a/arch/x86/kernel/irq.c
> +++ b/arch/x86/kernel/irq.c
> @@ -234,7 +234,7 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
>  	entering_irq();
> 
>  	/* entering_irq() tells RCU that we're not quiescent.  Check it. */
> -	rcu_lockdep_assert(rcu_is_watching(), "IRQ failed to wake up RCU");
> +	RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
> 
>  	irq = __this_cpu_read(vector_irq[vector]);
> 
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 980e4330fb59..fd2c9acbcc19 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -544,7 +544,7 @@ int notrace notify_die(enum die_val val, const char *str,
>  		.signr	= sig,
> 
>  	};
> -	rcu_lockdep_assert(rcu_is_watching(),
> +	RCU_LOCKDEP_WARN(!rcu_is_watching(),
>  			   "notify_die called but RCU thinks we're quiescent");
>  	return atomic_notifier_call_chain(&die_chain, val, &args);
>  }
> -- 
> 2.1.4
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 

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

* linux-next: build failure after merge of the rcu tree
@ 2015-07-16  3:14 Stephen Rothwell
  2015-07-16  3:51 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2015-07-16  3:14 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski

Hi Paul,

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

kernel/notifier.c: In function 'notify_die':
kernel/notifier.c:547:2: error: implicit declaration of function 'rcu_lockdep_assert' [-Werror=implicit-function-declaration]
  rcu_lockdep_assert(rcu_is_watching(),
  ^

Caused by commit

  02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")

interacting with commit

  e727c7d7a11e ("notifiers, RCU: Assert that RCU is watching in notify_die()")

[ and I also noted
  0333a209cbf6 ("x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion")
]

from the tip tree.

I added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Jul 2015 13:08:50 +1000
Subject: [PATCH] rcu: merge fix for Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/irq.c | 2 +-
 kernel/notifier.c     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 30dbf35bc90b..f9cd81825187 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -234,7 +234,7 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
 	entering_irq();
 
 	/* entering_irq() tells RCU that we're not quiescent.  Check it. */
-	rcu_lockdep_assert(rcu_is_watching(), "IRQ failed to wake up RCU");
+	RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
 
 	irq = __this_cpu_read(vector_irq[vector]);
 
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 980e4330fb59..fd2c9acbcc19 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -544,7 +544,7 @@ int notrace notify_die(enum die_val val, const char *str,
 		.signr	= sig,
 
 	};
-	rcu_lockdep_assert(rcu_is_watching(),
+	RCU_LOCKDEP_WARN(!rcu_is_watching(),
 			   "notify_die called but RCU thinks we're quiescent");
 	return atomic_notifier_call_chain(&die_chain, val, &args);
 }
-- 
2.1.4

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-04-13 11:34   ` Ingo Molnar
@ 2015-04-13 12:40     ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2015-04-13 12:40 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Borislav Petkov, Stephen Rothwell, linux-next, linux-kernel

On Mon, Apr 13, 2015 at 01:34:05PM +0200, Ingo Molnar wrote:
> 
> * Borislav Petkov <bp@suse.de> wrote:
> 
> > On Mon, Apr 13, 2015 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > > Hi Paul,
> > > 
> > > After merging the rcu tree, today's linux-next build (powerpc allnoconfig)
> > > failed like this:
> > > 
> > > init/main.c: In function 'rest_init':
> > > init/main.c:387:2: error: implicit declaration of function 'smpboot_thread_init' [-Werror=implicit-function-declaration]
> > >   smpboot_thread_init();
> > >   ^
> > > 
> > > Caused by commit c55f6e1f6f69 ("cpu: Defer smpboot kthread unparking
> > > until CPU known to scheduler").  The declaration in include/linux/cpu.h
> > > is protected by CONFIG_SMP, its use is not.
> > > 
> > > I have reverted that commit for today.
> > 
> > Thanks for the report Stephen, I know today is the day of b0rked
> > linux-next builds :-(
> > 
> > I think Ingo merged Paul's patch already so here's a fix ontop:
> 
> Yeah, I too triggered that build failure and fixed it locally.

What I get for immediately going to long-term testing.  The scenarios
that trigger this one were of course the last to run.  :-/

Thank you all, and apologies for the hassle!

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-04-13 11:06 ` Borislav Petkov
@ 2015-04-13 11:34   ` Ingo Molnar
  2015-04-13 12:40     ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Ingo Molnar @ 2015-04-13 11:34 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Stephen Rothwell, Paul E. McKenney, linux-next, linux-kernel


* Borislav Petkov <bp@suse.de> wrote:

> On Mon, Apr 13, 2015 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > After merging the rcu tree, today's linux-next build (powerpc allnoconfig)
> > failed like this:
> > 
> > init/main.c: In function 'rest_init':
> > init/main.c:387:2: error: implicit declaration of function 'smpboot_thread_init' [-Werror=implicit-function-declaration]
> >   smpboot_thread_init();
> >   ^
> > 
> > Caused by commit c55f6e1f6f69 ("cpu: Defer smpboot kthread unparking
> > until CPU known to scheduler").  The declaration in include/linux/cpu.h
> > is protected by CONFIG_SMP, its use is not.
> > 
> > I have reverted that commit for today.
> 
> Thanks for the report Stephen, I know today is the day of b0rked
> linux-next builds :-(
> 
> I think Ingo merged Paul's patch already so here's a fix ontop:

Yeah, I too triggered that build failure and fixed it locally.

Thanks,

	Ingo

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

* Re: linux-next: build failure after merge of the rcu tree
  2015-04-13 10:39 Stephen Rothwell
@ 2015-04-13 11:06 ` Borislav Petkov
  2015-04-13 11:34   ` Ingo Molnar
  0 siblings, 1 reply; 101+ messages in thread
From: Borislav Petkov @ 2015-04-13 11:06 UTC (permalink / raw)
  To: Stephen Rothwell, Ingo Molnar; +Cc: Paul E. McKenney, linux-next, linux-kernel

On Mon, Apr 13, 2015 at 08:39:17PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc allnoconfig)
> failed like this:
> 
> init/main.c: In function 'rest_init':
> init/main.c:387:2: error: implicit declaration of function 'smpboot_thread_init' [-Werror=implicit-function-declaration]
>   smpboot_thread_init();
>   ^
> 
> Caused by commit c55f6e1f6f69 ("cpu: Defer smpboot kthread unparking
> until CPU known to scheduler").  The declaration in include/linux/cpu.h
> is protected by CONFIG_SMP, its use is not.
> 
> I have reverted that commit for today.

Thanks for the report Stephen, I know today is the day of b0rked
linux-next builds :-(

I think Ingo merged Paul's patch already so here's a fix ontop:

---
From: Borislav Petkov <bp@suse.de>
Date: Mon, 13 Apr 2015 13:01:32 +0200
Subject: [PATCH] smpboot: Fix CONFIG_SMP=n build

Stephen Rothwell reported a CONFIG_SMP=n breakage with latest rcu/next.
The timing of this is very unfortunate as we've been hunting this bug
hastily over the weekend, just to be in time for the merge window.

So here's a fix ontop.

Signed-off-by: Borislav Petkov <bp@suse.de>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: <x86@kernel.org>
Link: http://lkml.kernel.org/r/20150413203917.1e7ea535@canb.auug.org.au
---
 include/linux/cpu.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 091badf0f6ba..bbdee1e6cf48 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -198,6 +198,10 @@ static inline void __unregister_cpu_notifier(struct notifier_block *nb)
 {
 }
 
+static inline void smpboot_thread_init(void)
+{
+}
+
 static inline void cpu_maps_update_begin(void)
 {
 }
-- 
2.3.5

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

* linux-next: build failure after merge of the rcu tree
@ 2015-04-13 10:39 Stephen Rothwell
  2015-04-13 11:06 ` Borislav Petkov
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2015-04-13 10:39 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Borislav Petkov

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

Hi Paul,

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

init/main.c: In function 'rest_init':
init/main.c:387:2: error: implicit declaration of function 'smpboot_thread_init' [-Werror=implicit-function-declaration]
  smpboot_thread_init();
  ^

Caused by commit c55f6e1f6f69 ("cpu: Defer smpboot kthread unparking
until CPU known to scheduler").  The declaration in include/linux/cpu.h
is protected by CONFIG_SMP, its use is not.

I have reverted that commit 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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2015-02-27  2:18 Stephen Rothwell
@ 2015-02-27  5:59 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2015-02-27  5:59 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Fri, Feb 27, 2015 at 01:18:56PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> arch/x86/xen/smp.c: In function 'xen_cpu_up':
> arch/x86/xen/smp.c:460:6: error: 'err' undeclared (first use in this function)
>   if (err)
>       ^
> 
> Caused by commit b92c23b083d6 ("x86: Use common
> outgoing-CPU-notification code").
> 
> I have used the rcu tree from next-20150226 for today.

Apologies for the hassle!  I have fixed this.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2015-02-27  2:18 Stephen Rothwell
  2015-02-27  5:59 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2015-02-27  2:18 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel

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

Hi Paul,

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

arch/x86/xen/smp.c: In function 'xen_cpu_up':
arch/x86/xen/smp.c:460:6: error: 'err' undeclared (first use in this function)
  if (err)
      ^

Caused by commit b92c23b083d6 ("x86: Use common
outgoing-CPU-notification code").

I have used the rcu tree from next-20150226 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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-27 17:20     ` Pranith Kumar
@ 2014-12-31  1:45       ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2014-12-31  1:45 UTC (permalink / raw)
  To: Pranith Kumar; +Cc: Stephen Rothwell, linux-next, LKML

On Sat, Dec 27, 2014 at 12:20:50PM -0500, Pranith Kumar wrote:
> On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar <bobby.prani@gmail.com> wrote:
> > On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
> >> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
> >> "select SRCU" to "config PPC" in arch/powerpc/Kconfig.  Are you able
> >> to cross-build powerpc?
> >>
> >
> > ppc 32 seems fine without selecting srcu unconditionally. So I added
> > this select to PPC 64 which should fix this build failure.
> 
> On looking at this further, I was able to figure out the parts on
> ppc64 utilizing KVM and enabled them dependent on CONFIG_KVM being
> enabled. I tested this with a ppc64 allnoconfig and it built
> succesfully (depending on a unrelated patch to enable printk for
> powernv).
> 
> I've sent the patch but it still seems that we will be playing
> whack-a-mole for now with code which uses KVM indepedent of
> CONFIG_KVM. May be fixing it incrementally is a better option than
> lumping all these together?

For PPC64, I suggest starting with something that can be trivially shown
to work, even if it consumes more memory than required.  The PPC64 systems
almost always have an abundance of memory, so having SRCU unnecessarily
built into the system is not all that bad -- and is what happens today
anyway.

Given that starting point, you can then build a more precise patch for
PPC64 on top of the starting-point patch.

Make sense?

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-27 16:24   ` Pranith Kumar
@ 2014-12-27 17:20     ` Pranith Kumar
  2014-12-31  1:45       ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Pranith Kumar @ 2014-12-27 17:20 UTC (permalink / raw)
  To: Paul McKenney; +Cc: Stephen Rothwell, linux-next, LKML

On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar <bobby.prani@gmail.com> wrote:
> On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
>> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
>> "select SRCU" to "config PPC" in arch/powerpc/Kconfig.  Are you able
>> to cross-build powerpc?
>>
>
> ppc 32 seems fine without selecting srcu unconditionally. So I added
> this select to PPC 64 which should fix this build failure.
>

On looking at this further, I was able to figure out the parts on
ppc64 utilizing KVM and enabled them dependent on CONFIG_KVM being
enabled. I tested this with a ppc64 allnoconfig and it built
succesfully (depending on a unrelated patch to enable printk for
powernv).

I've sent the patch but it still seems that we will be playing
whack-a-mole for now with code which uses KVM indepedent of
CONFIG_KVM. May be fixing it incrementally is a better option than
lumping all these together?

-- 
Pranith

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

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-26 16:54 ` Paul E. McKenney
@ 2014-12-27 16:24   ` Pranith Kumar
  2014-12-27 17:20     ` Pranith Kumar
  0 siblings, 1 reply; 101+ messages in thread
From: Pranith Kumar @ 2014-12-27 16:24 UTC (permalink / raw)
  To: Paul McKenney; +Cc: Stephen Rothwell, linux-next, LKML

On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
> "select SRCU" to "config PPC" in arch/powerpc/Kconfig.  Are you able
> to cross-build powerpc?
>

ppc 32 seems fine without selecting srcu unconditionally. So I added
this select to PPC 64 which should fix this build failure.

I will send the updated patch once I've done some basic tests. Sorry
for the delay!

-- 
Pranith

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

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-26  7:51 Stephen Rothwell
@ 2014-12-26 16:54 ` Paul E. McKenney
  2014-12-27 16:24   ` Pranith Kumar
  0 siblings, 1 reply; 101+ messages in thread
From: Paul E. McKenney @ 2014-12-26 16:54 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Pranith Kumar

On Fri, Dec 26, 2014 at 06:51:20PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
>                  from arch/powerpc/kernel/setup_64.c:68:
> include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
>   struct srcu_struct srcu;
>                      ^
> include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
>   struct srcu_struct irq_srcu;
>                      ^
> 
> Caused by commit f01a973369dd ("srcu: Isolate srcu sections using
> CONFIG_SRCU").  Please stop readding that commit after until it is
> fixed :-(
> 
> I have reverted that commit for today (again :-().

Hello, Stephen,

Please accept my apologies for the hassle!  I had removed that commit
for the duration of the merge window, and forgotten about it when I
re-added all my non-3.19 commits.  :-/

Could you please send your .config?  Or let me know whether it has
CONFIG_KVM=n?

Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
"select SRCU" to "config PPC" in arch/powerpc/Kconfig.  Are you able
to cross-build powerpc?

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2014-12-26  7:51 Stephen Rothwell
  2014-12-26 16:54 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2014-12-26  7:51 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Pranith Kumar

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

Hi Paul,

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

In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
                 from arch/powerpc/kernel/setup_64.c:68:
include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
  struct srcu_struct srcu;
                     ^
include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
  struct srcu_struct irq_srcu;
                     ^

Caused by commit f01a973369dd ("srcu: Isolate srcu sections using
CONFIG_SRCU").  Please stop readding that commit after until it is
fixed :-(

I have reverted that commit for today (again :-().

-- 
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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-12  6:12 Stephen Rothwell
@ 2014-12-12 17:23 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2014-12-12 17:23 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Pranith Kumar

On Fri, Dec 12, 2014 at 05:12:15PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
>                  from arch/powerpc/kernel/setup_64.c:68:
> include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
>   struct srcu_struct srcu;
>                      ^
> include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
>   struct srcu_struct irq_srcu;
>                      ^
> 
> I am sure we have seen this before :-(
> 
> Caused by commit 31a78b1b598a ("srcu: Isolate srcu sections using
> CONFIG_SRCU") as it was before (I do wonder why this came back).
> 
> I have reverted that commit for today.

Gah...  I forgot to adjust rcu/next placement for the merge window!!!
Please accept my apologies, I have set it up to include only the
commits destined for 3.19.  :-/

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2014-12-12  6:12 Stephen Rothwell
  2014-12-12 17:23 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2014-12-12  6:12 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Pranith Kumar

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

Hi Paul,

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

In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
                 from arch/powerpc/kernel/setup_64.c:68:
include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
  struct srcu_struct srcu;
                     ^
include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
  struct srcu_struct irq_srcu;
                     ^

I am sure we have seen this before :-(

Caused by commit 31a78b1b598a ("srcu: Isolate srcu sections using
CONFIG_SRCU") as it was before (I do wonder why this came back).

I have reverted that commit 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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-10 15:03 ` Pranith Kumar
@ 2014-12-10 15:18   ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2014-12-10 15:18 UTC (permalink / raw)
  To: Pranith Kumar; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Wed, Dec 10, 2014 at 10:03:57AM -0500, Pranith Kumar wrote:
> On 12/10/2014 03:09 AM, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > After merging the rcu tree, today's linux-next build (powerpc64
> > allnoconfig) failed like this:
> > 
> > In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
> >                  from arch/powerpc/kernel/setup_64.c:68:
> > include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
> >   struct srcu_struct srcu;
> >                      ^
> > include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
> >   struct srcu_struct irq_srcu;
> >                      ^
> > 
> > Presumably caused by commit 6e8ef258b669 ("srcu: Isolate srcu sections
> > using CONFIG_SRCU").
> > 
> > I have reverted that commit again for today - more work required ...
> > 
> 
> Looks like there are other places which use KVM unconditionally. I will try to look and fix such uses. 
> 
> Paul, can you drop the patch until then? Thanks!

Done!

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-10  8:09 Stephen Rothwell
@ 2014-12-10 15:03 ` Pranith Kumar
  2014-12-10 15:18   ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Pranith Kumar @ 2014-12-10 15:03 UTC (permalink / raw)
  To: Stephen Rothwell, Paul E. McKenney; +Cc: linux-next, linux-kernel

On 12/10/2014 03:09 AM, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
>                  from arch/powerpc/kernel/setup_64.c:68:
> include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
>   struct srcu_struct srcu;
>                      ^
> include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
>   struct srcu_struct irq_srcu;
>                      ^
> 
> Presumably caused by commit 6e8ef258b669 ("srcu: Isolate srcu sections
> using CONFIG_SRCU").
> 
> I have reverted that commit again for today - more work required ...
> 

Looks like there are other places which use KVM unconditionally. I will try to look and fix such uses. 

Paul, can you drop the patch until then? Thanks!
--
Pranith

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

* linux-next: build failure after merge of the rcu tree
@ 2014-12-10  8:09 Stephen Rothwell
  2014-12-10 15:03 ` Pranith Kumar
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2014-12-10  8:09 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Pranith Kumar

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

Hi Paul,

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

In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
                 from arch/powerpc/kernel/setup_64.c:68:
include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
  struct srcu_struct srcu;
                     ^
include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
  struct srcu_struct irq_srcu;
                     ^

Presumably caused by commit 6e8ef258b669 ("srcu: Isolate srcu sections
using CONFIG_SRCU").

I have reverted that commit again for today - more work required ...

-- 
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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2014-12-09 11:42 Stephen Rothwell
@ 2014-12-09 14:07 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2014-12-09 14:07 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Pranith Kumar

On Tue, Dec 09, 2014 at 10:42:30PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
> include/linux/notifier.h:51:4: warning: its scope is only this definition or declaration, which is probably not what you want
> In file included from include/linux/memory_hotplug.h:6:0,
>                  from include/linux/mmzone.h:790,
>                  from include/linux/gfp.h:5,
>                  from arch/powerpc/mm/pgtable.c:25:
> include/linux/notifier.h:51:4: error: 'struct notifier_block' declared inside parameter list [-Werror]
>     unsigned long action, void *data);
>     ^
> 
> And many more (most just warnings ...).
> 
> Presumably caused by commit 44dec3761b63 ("srcu: Isolate srcu sections
> using CONFIG_SRCU") and reverting that commit makes the messages go
> away, so I have done that for today.

Apologies, I forgot to push the fix to rcu/next, will do.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2014-12-09 11:42 Stephen Rothwell
  2014-12-09 14:07 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2014-12-09 11:42 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Pranith Kumar

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

Hi Paul,

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

include/linux/notifier.h:51:4: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from include/linux/memory_hotplug.h:6:0,
                 from include/linux/mmzone.h:790,
                 from include/linux/gfp.h:5,
                 from arch/powerpc/mm/pgtable.c:25:
include/linux/notifier.h:51:4: error: 'struct notifier_block' declared inside parameter list [-Werror]
    unsigned long action, void *data);
    ^

And many more (most just warnings ...).

Presumably caused by commit 44dec3761b63 ("srcu: Isolate srcu sections
using CONFIG_SRCU") and reverting that commit makes the messages go
away, so I have done that 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] 101+ messages in thread

* Re: linux-next: build failure after merge of the rcu tree
  2012-04-16  4:11 Stephen Rothwell
@ 2012-04-16 17:02 ` Paul E. McKenney
  0 siblings, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2012-04-16 17:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Linus Torvalds, Paul E. McKenney

On Mon, Apr 16, 2012 at 02:11:17PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/binfmt_misc.c: In function 'create_entry':
> fs/binfmt_misc.c:314:2: error: implicit declaration of function '_copy_from_user' [-Werror=implicit-function-declaration]
> 
> Caused by commit d17faaa53e2e ("fs: Silence bogus copy_to_user() build
> errors").  _copy_from_user() appears to only exist for the x86 and tile
> architectures ...
> 
> I have used the rcu tree from next-20120413 for today.

<red face>

It turns out that bug that commit d17faaa53e2e was working around has
been fixed in 3.4-rc2, so I have dropped that patch and reposted the
series.  Please accept my apologies for the hassle!

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2012-04-16  4:11 Stephen Rothwell
  2012-04-16 17:02 ` Paul E. McKenney
  0 siblings, 1 reply; 101+ messages in thread
From: Stephen Rothwell @ 2012-04-16  4:11 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Linus Torvalds, Paul E. McKenney

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

Hi Paul,

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

fs/binfmt_misc.c: In function 'create_entry':
fs/binfmt_misc.c:314:2: error: implicit declaration of function '_copy_from_user' [-Werror=implicit-function-declaration]

Caused by commit d17faaa53e2e ("fs: Silence bogus copy_to_user() build
errors").  _copy_from_user() appears to only exist for the x86 and tile
architectures ...

I have used the rcu tree from next-20120413 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2010-09-17  2:42 Stephen Rothwell
  2010-09-17  4:39 ` David Miller
@ 2010-09-17 23:17 ` Paul E. McKenney
  1 sibling, 0 replies; 101+ messages in thread
From: Paul E. McKenney @ 2010-09-17 23:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev

On Fri, Sep 17, 2010 at 12:42:38PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> net/core/dev.c: In function 'netdev_run_todo':
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of '_________p1'
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
> net/core/dev.c:5294: warning: comparison of distinct pointer types lacks a cast
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
> 
> Caused by commit ca5ecddfa8fcbd948c95530e7e817cee9fb43a3d ("rcu: define
> __rcu address space modifier for sparse") interacting with commit
> 95ae6b228f814fc0528d0506ee9f18ac333d6851 ("ipv4: ip_ptr cleanups") from
> the net tree.
> 
> rcu_dereference_raw() now needs to know the type of the object its
> argument points to.  I added the following merge fix (which could be
> applied to the net tree anyway).
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Sep 2010 12:36:36 +1000
> Subject: [PATCH] net: include inetdevice.h for rcu_dereference_raw api change
> 
> rcu_dereference_raw() now needs to know the type of its argument.

Good catch, thank you!!!

							Thanx, Paul

> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  net/core/dev.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index c6d837a..cadd28c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -129,6 +129,7 @@
>  #include <linux/random.h>
>  #include <trace/events/napi.h>
>  #include <linux/pci.h>
> +#include <linux/inetdevice.h>
> 
>  #include "net-sysfs.h"
> 
> -- 
> 1.7.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

* Re: linux-next: build failure after merge of the rcu tree
  2010-09-17  4:39 ` David Miller
@ 2010-09-17  5:34   ` Eric Dumazet
  0 siblings, 0 replies; 101+ messages in thread
From: Eric Dumazet @ 2010-09-17  5:34 UTC (permalink / raw)
  To: David Miller; +Cc: sfr, paulmck, linux-next, linux-kernel, netdev

Le jeudi 16 septembre 2010 à 21:39 -0700, David Miller a écrit :
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Sep 2010 12:42:38 +1000
> 
> > Subject: [PATCH] net: include inetdevice.h for rcu_dereference_raw api change
> > 
> > rcu_dereference_raw() now needs to know the type of its argument.
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> I've tossed this into net-next-2.6, thanks!

Thanks guys

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

* Re: linux-next: build failure after merge of the rcu tree
  2010-09-17  2:42 Stephen Rothwell
@ 2010-09-17  4:39 ` David Miller
  2010-09-17  5:34   ` Eric Dumazet
  2010-09-17 23:17 ` Paul E. McKenney
  1 sibling, 1 reply; 101+ messages in thread
From: David Miller @ 2010-09-17  4:39 UTC (permalink / raw)
  To: sfr; +Cc: paulmck, linux-next, linux-kernel, eric.dumazet, netdev

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Sep 2010 12:42:38 +1000

> Subject: [PATCH] net: include inetdevice.h for rcu_dereference_raw api change
> 
> rcu_dereference_raw() now needs to know the type of its argument.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

I've tossed this into net-next-2.6, thanks!

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

* linux-next: build failure after merge of the rcu tree
@ 2010-09-17  2:42 Stephen Rothwell
  2010-09-17  4:39 ` David Miller
  2010-09-17 23:17 ` Paul E. McKenney
  0 siblings, 2 replies; 101+ messages in thread
From: Stephen Rothwell @ 2010-09-17  2:42 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev

Hi Paul,

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

net/core/dev.c: In function 'netdev_run_todo':
net/core/dev.c:5294: error: dereferencing pointer to incomplete type
net/core/dev.c:5294: warning: type defaults to 'int' in declaration of '_________p1'
net/core/dev.c:5294: error: dereferencing pointer to incomplete type
net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
net/core/dev.c:5294: error: dereferencing pointer to incomplete type
net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
net/core/dev.c:5294: warning: comparison of distinct pointer types lacks a cast
net/core/dev.c:5294: error: dereferencing pointer to incomplete type
net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'

Caused by commit ca5ecddfa8fcbd948c95530e7e817cee9fb43a3d ("rcu: define
__rcu address space modifier for sparse") interacting with commit
95ae6b228f814fc0528d0506ee9f18ac333d6851 ("ipv4: ip_ptr cleanups") from
the net tree.

rcu_dereference_raw() now needs to know the type of the object its
argument points to.  I added the following merge fix (which could be
applied to the net tree anyway).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Sep 2010 12:36:36 +1000
Subject: [PATCH] net: include inetdevice.h for rcu_dereference_raw api change

rcu_dereference_raw() now needs to know the type of its argument.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/core/dev.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index c6d837a..cadd28c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -129,6 +129,7 @@
 #include <linux/random.h>
 #include <trace/events/napi.h>
 #include <linux/pci.h>
+#include <linux/inetdevice.h>
 
 #include "net-sysfs.h"
 
-- 
1.7.1

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

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

end of thread, back to index

Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-12  6:12 linux-next: build failure after merge of the rcu tree Stephen Rothwell
2019-08-12 16:19 ` Paul E. McKenney
2019-08-13  5:25   ` Stephen Rothwell
2019-08-13 14:38     ` Paul E. McKenney
  -- strict thread matches above, loose matches on Subject: below --
2019-08-13  7:57 Stephen Rothwell
2019-08-13 15:31 ` Paul E. McKenney
2017-09-04  4:50 Stephen Rothwell
2017-09-04 16:39 ` Paul E. McKenney
2017-08-28  4:25 Stephen Rothwell
2017-08-28 17:50 ` Paul E. McKenney
2017-08-11  4:43 Stephen Rothwell
2017-08-11  4:54 ` Paul E. McKenney
2017-08-11  9:14   ` Peter Zijlstra
2017-08-11 14:39     ` Paul E. McKenney
2017-08-11 14:45       ` Peter Zijlstra
2017-08-11 14:41     ` Peter Zijlstra
2017-08-11 20:12       ` Paul E. McKenney
2017-05-29  6:02 Stephen Rothwell
2017-05-29 21:15 ` Paul E. McKenney
2017-05-30  1:40   ` Stephen Rothwell
2017-05-30  1:54     ` Joe Perches
2017-05-30  2:14       ` Paul E. McKenney
2017-05-30  2:20         ` Joe Perches
2017-05-30  3:13           ` Stephen Rothwell
2017-05-30  4:10   ` Michael Ellerman
2017-06-02 17:51     ` Paul E. McKenney
2017-04-20  5:36 Stephen Rothwell
2017-04-20 14:23 ` Paul E. McKenney
2017-04-19  3:50 Stephen Rothwell
2017-04-19  4:06 ` Paul E. McKenney
2017-04-19  5:45   ` Stephen Rothwell
2017-03-08  1:16 Stephen Rothwell
2017-03-08 10:13 ` Daniel Vetter
2017-03-08 17:40   ` Paul E. McKenney
2017-01-19  3:34 Stephen Rothwell
2017-01-19 21:54 ` Paul McKenney
2017-02-13  2:21   ` Stephen Rothwell
2017-02-13  4:37     ` Paul E. McKenney
2017-02-13  6:43       ` Stephen Rothwell
2017-03-08  1:16         ` Stephen Rothwell
2017-03-08  1:37           ` Paul E. McKenney
2017-03-08 18:05           ` Paul E. McKenney
2016-05-02  4:37 Stephen Rothwell
2016-05-02 11:06 ` Paul E. McKenney
2016-02-01  2:55 Stephen Rothwell
2016-02-01  9:53 ` Paul E. McKenney
2016-01-07  8:57 Stephen Rothwell
2016-01-07 18:02 ` Paul E. McKenney
2016-01-07 20:19   ` Stephen Rothwell
2016-01-07 20:52     ` Paul E. McKenney
2016-01-08  1:37       ` Boqun Feng
2016-01-08  3:41         ` Paul E. McKenney
2016-01-08  4:08           ` Stephen Rothwell
2016-01-08  4:48             ` Paul E. McKenney
2016-01-08  4:54               ` Boqun Feng
2016-01-08 15:53                 ` Paul E. McKenney
2016-01-08 15:57                   ` Tejun Heo
2016-01-08 16:18                     ` Paul E. McKenney
2016-01-08 15:58                   ` Boqun Feng
2016-01-08  4:10         ` Stephen Rothwell
2015-09-01  3:50 Stephen Rothwell
2015-09-01  7:49 ` Paul E. McKenney
2015-09-02  3:58   ` Stephen Rothwell
2015-09-02  5:26     ` Paul E. McKenney
2015-09-02  6:40       ` Davidlohr Bueso
2015-09-02  7:14         ` Paul E. McKenney
2015-09-02  7:29           ` Ingo Molnar
2015-09-02  8:34             ` Paul E. McKenney
2015-07-16  3:14 Stephen Rothwell
2015-07-16  3:51 ` Paul E. McKenney
2015-07-16  5:50   ` Stephen Rothwell
2015-07-17 11:40   ` Ingo Molnar
2015-07-17 17:35     ` Paul E. McKenney
2015-07-17 18:53       ` Paul E. McKenney
2015-07-17 19:51         ` Ingo Molnar
2015-07-17 21:33           ` Paul E. McKenney
2015-07-18  2:40             ` Ingo Molnar
2015-04-13 10:39 Stephen Rothwell
2015-04-13 11:06 ` Borislav Petkov
2015-04-13 11:34   ` Ingo Molnar
2015-04-13 12:40     ` Paul E. McKenney
2015-02-27  2:18 Stephen Rothwell
2015-02-27  5:59 ` Paul E. McKenney
2014-12-26  7:51 Stephen Rothwell
2014-12-26 16:54 ` Paul E. McKenney
2014-12-27 16:24   ` Pranith Kumar
2014-12-27 17:20     ` Pranith Kumar
2014-12-31  1:45       ` Paul E. McKenney
2014-12-12  6:12 Stephen Rothwell
2014-12-12 17:23 ` Paul E. McKenney
2014-12-10  8:09 Stephen Rothwell
2014-12-10 15:03 ` Pranith Kumar
2014-12-10 15:18   ` Paul E. McKenney
2014-12-09 11:42 Stephen Rothwell
2014-12-09 14:07 ` Paul E. McKenney
2012-04-16  4:11 Stephen Rothwell
2012-04-16 17:02 ` Paul E. McKenney
2010-09-17  2:42 Stephen Rothwell
2010-09-17  4:39 ` David Miller
2010-09-17  5:34   ` Eric Dumazet
2010-09-17 23:17 ` Paul E. McKenney

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org linux-next@archiver.kernel.org
	public-inbox-index linux-next


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/ public-inbox