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

[Paul E. McKenney]

On Wed, Mar 17, 2021 at 04:36:13PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: modpost: "rcu_read_lock_longwait_held" [kernel/rcu/rcutorture.ko] 
> undefined!
> ERROR: modpost: "rcu_read_unlock_longwait" [kernel/rcu/rcutorture.ko] 
> undefined!
> ERROR: modpost: "rcu_read_lock_longwait" [kernel/rcu/rcutorture.ko] undefined!
> 
> Caused by commit
> 
>   bd6ae31d1b1f ("rcutorture: Add the ability to torture RCU longsleep")
> 
> CONFIG_LONGWAIT_RCU=y
> CONFIG_RCU_TORTURE_TEST=m
> 
> I have used the rcu tree from next-20210316 for today.

Gah!  Rebase first, then retest, -then- adjust rcu/next...

Will fix, apologies for the hassle!

Thanx, Paul

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

[Frederic Weisbecker]

On Mon, Jan 04, 2021 at 11:37:36AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> arch/arm/mach-imx/cpuidle-imx6q.c: In function 'imx6q_enter_wait':
> arch/arm/mach-imx/cpuidle-imx6q.c:32:7: error: implicit declaration of 
> function 'need_resched'; did you mean 'tif_need_resched'? 
> [-Werror=implicit-function-declaration]
>32 |  if (!need_resched())
>   |   ^~~~
>   |   tif_need_resched
> 
> Caused by commit
> 
>   7ca83ec735ce ("ARM: imx6q: Fix missing need_resched() check after
>   rcu_idle_enter()")

Thanks for the report, I'm checking that.

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

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

[Stephen Rothwell]

Hi Paul,

On Sun, 6 Dec 2020 20:48:41 -0800 "Paul E. McKenney"  wrote:
>
> On Mon, Dec 07, 2020 at 08:39:20AM +1100, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > On Fri, 4 Dec 2020 11:20:32 -0800 "Paul E. McKenney"  
> > wrote:  
> > >
> > > Does the following patch fix things?  (Sigh.  It won't apply on the
> > > rcu/next that you used.  Or even on this moment's dev branch.  I will
> > > fold it in with attribution and update.  But just to show you what my
> > > thought is.)  
> > 
> > Sorry I didn't get the chance to test your patch, but it seems to make
> > sense.  I notice that you have added this to the rcu tree for today, so
> > I guess we will see :-)  
> 
> Fair enough!  ;-)

And it built fine, thanks.

-- 
Cheers,
Stephen Rothwell


pgpubXUoCu19Q.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

On Mon, Dec 07, 2020 at 08:39:20AM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Fri, 4 Dec 2020 11:20:32 -0800 "Paul E. McKenney"  
> wrote:
> >
> > Does the following patch fix things?  (Sigh.  It won't apply on the
> > rcu/next that you used.  Or even on this moment's dev branch.  I will
> > fold it in with attribution and update.  But just to show you what my
> > thought is.)
> 
> Sorry I didn't get the chance to test your patch, but it seems to make
> sense.  I notice that you have added this to the rcu tree for today, so
> I guess we will see :-)

Fair enough!  ;-)

Thanx, Paul

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

[Stephen Rothwell]

Hi Paul,

On Fri, 4 Dec 2020 11:20:32 -0800 "Paul E. McKenney"  wrote:
>
> Does the following patch fix things?  (Sigh.  It won't apply on the
> rcu/next that you used.  Or even on this moment's dev branch.  I will
> fold it in with attribution and update.  But just to show you what my
> thought is.)

Sorry I didn't get the chance to test your patch, but it seems to make
sense.  I notice that you have added this to the rcu tree for today, so
I guess we will see :-)

-- 
Cheers,
Stephen Rothwell


pgpG_ikyXeLCe.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

On Fri, Dec 04, 2020 at 07:25:26PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (sparc defconfig)
> failed like this:
> 
> mm/slab_common.o: In function `kmem_last_alloc':
> slab_common.c:(.text+0xc4): undefined reference to `kmem_cache_last_alloc'
> 
> Caused by commit
> 
>   f7c3fb4fc476 ("mm: Add kmem_last_alloc() to return last allocation for 
> memory block")
> 
> in mm/slab.c, kmem_cache_last_alloc() is only defined when CONFIG_NUMA
> is set - which is not for this build.
> 
> I applied the following hack fix patch for today.
> 
> From ac5dcf78be1e6da530302966369a3bd63007cf81 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell 
> Date: Fri, 4 Dec 2020 19:11:01 +1100
> Subject: [PATCH] fixup for "mm: Add kmem_last_alloc() to return last
>  allocation for memory block"
> 
> Signed-off-by: Stephen Rothwell 

Apologies for the hassle and thank you for the very helpful "hack
fix patch".  The kbuild test robot also found this, but I hadn't
quite gotten it through my head that the only slab definition of the
kmem_cache_last_alloc() was under CONFIG_NUMA.

Does the following patch fix things?  (Sigh.  It won't apply on the
rcu/next that you used.  Or even on this moment's dev branch.  I will
fold it in with attribution and update.  But just to show you what my
thought is.)

Thanx, Paul



diff --git a/mm/slab.c b/mm/slab.c
index 87aa2c0..ae1a74c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3602,27 +3602,6 @@ void *kmem_cache_alloc_node_trace(struct kmem_cache 
*cachep,
 EXPORT_SYMBOL(kmem_cache_alloc_node_trace);
 #endif
 
-void *kmem_cache_last_alloc(struct kmem_cache *cachep, void *object, void 
**stackp, int nstackp)
-{
-#ifdef DEBUG
-   unsigned int objnr;
-   void *objp;
-   struct page *page;
-
-   if (!(cachep->flags & SLAB_STORE_USER))
-   return ERR_PTR(-KMEM_LA_NO_DEBUG);
-   objp = object - obj_offset(cachep);
-   page = virt_to_head_page(objp);
-   objnr = obj_to_index(cachep, page, objp);
-   objp = index_to_obj(cachep, page, objnr);
-   if (stackp && nstackp)
-   stackp[0] = NULL;
-   return *dbg_userword(cachep, objp);
-#else
-   return NULL;
-#endif
-}
-
 static __always_inline void *
 __do_kmalloc_node(size_t size, gfp_t flags, int node, unsigned long caller)
 {
@@ -3654,6 +3633,27 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t 
flags,
 EXPORT_SYMBOL(__kmalloc_node_track_caller);
 #endif /* CONFIG_NUMA */
 
+void *kmem_cache_last_alloc(struct kmem_cache *cachep, void *object, void 
**stackp, int nstackp)
+{
+#ifdef DEBUG
+   unsigned int objnr;
+   void *objp;
+   struct page *page;
+
+   if (!(cachep->flags & SLAB_STORE_USER))
+   return ERR_PTR(-KMEM_LA_NO_DEBUG);
+   objp = object - obj_offset(cachep);
+   page = virt_to_head_page(objp);
+   objnr = obj_to_index(cachep, page, objp);
+   objp = index_to_obj(cachep, page, objnr);
+   if (stackp && nstackp)
+   stackp[0] = NULL;
+   return *dbg_userword(cachep, objp);
+#else
+   return NULL;
+#endif
+}
+
 /**
  * __do_kmalloc - allocate memory
  * @size: how many bytes of memory are required.

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

[Stephen Rothwell]

Hi Paul,

On Thu, 17 Sep 2020 15:01:45 -0700 "Paul E. McKenney"  
wrote:
>
> On Thu, Sep 17, 2020 at 03:19:09PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the rcu tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from kernel/rcu/update.c:578:
> > kernel/rcu/tasks.h:601:20: error: static declaration of 
> > 'show_rcu_tasks_classic_gp_kthread' follows non-static declaration
> >   601 | static inline void show_rcu_tasks_classic_gp_kthread(void) { }
> >   |^
> > In file included from kernel/rcu/update.c:49:
> > kernel/rcu/rcu.h:537:6: note: previous declaration of 
> > 'show_rcu_tasks_classic_gp_kthread' was here
> >   537 | void show_rcu_tasks_classic_gp_kthread(void);
> >   |  ^
> > 
> > Caused by commit
> > 
> >   675d3ca52626 ("rcutorture: Make grace-period kthread report match RCU 
> > flavor being tested")
> > 
> > I have used the rcu tree from next-20200916 for today.  
> 
> Please accept my apologies for the hassle!  I believe that I finally
> have this straightened out.
> 
> Please ignore if you already pulled -rcu for today, as I previously
> set rcu/next back to a commit preceding the offending one.

No worries, I have the new one.

-- 
Cheers,
Stephen Rothwell


pgpg1BvmPOioj.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

On Thu, Sep 17, 2020 at 03:19:09PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from kernel/rcu/update.c:578:
> kernel/rcu/tasks.h:601:20: error: static declaration of 
> 'show_rcu_tasks_classic_gp_kthread' follows non-static declaration
>   601 | static inline void show_rcu_tasks_classic_gp_kthread(void) { }
>   |^
> In file included from kernel/rcu/update.c:49:
> kernel/rcu/rcu.h:537:6: note: previous declaration of 
> 'show_rcu_tasks_classic_gp_kthread' was here
>   537 | void show_rcu_tasks_classic_gp_kthread(void);
>   |  ^
> 
> Caused by commit
> 
>   675d3ca52626 ("rcutorture: Make grace-period kthread report match RCU 
> flavor being tested")
> 
> I have used the rcu tree from next-20200916 for today.

Please accept my apologies for the hassle!  I believe that I finally
have this straightened out.

Please ignore if you already pulled -rcu for today, as I previously
set rcu/next back to a commit preceding the offending one.

Thanx, Paul

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

[Paul E. McKenney]

On Tue, Sep 08, 2020 at 03:38:30PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: modpost: "resched_cpu" [kernel/scftorture.ko] undefined!
> 
> Caused by commit
> 
>   20c881d0592c ("scftorture: Add an alternative IPI vector")
> 
> I have reverted that commit for today.

Good catch, (crudely) fixed by 007d16a07735 ("scftorture: Add an
alternative IPI vector") in the new rcu/next branch.

Thanx, Paul

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

[Paul E. McKenney]

On Tue, Aug 18, 2020 at 11:43:54AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from include/linux/kernel.h:15,
>  from kernel/rcu/rcuscale.c:13:
> kernel/rcu/rcuscale.c: In function 'rcu_scale_writer':
> kernel/rcu/rcuscale.c:430:6: error: 'perf_type' undeclared (first use in this 
> function); did you mean 'kernfs_type'?
>   430 |  perf_type, PERF_FLAG, me, MIN_MEAS);
>   |  ^
> include/linux/printk.h:319:35: note: in definition of macro 'pr_alert'
>   319 |  printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
>   |   ^~~
> kernel/rcu/rcuscale.c:430:6: note: each undeclared identifier is reported 
> only once for each function it appears in
>   430 |  perf_type, PERF_FLAG, me, MIN_MEAS);
>   |  ^
> include/linux/printk.h:319:35: note: in definition of macro 'pr_alert'
>   319 |  printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
>   |   ^~~
> kernel/rcu/rcuscale.c:430:17: error: 'PERF_FLAG' undeclared (first use in 
> this function)
>   430 |  perf_type, PERF_FLAG, me, MIN_MEAS);
>   | ^
> include/linux/printk.h:319:35: note: in definition of macro 'pr_alert'
>   319 |  printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
>   |   ^~~
> kernel/rcu/rcuscale.c:431:27: error: 'n_rcu_perf_writer_finished' undeclared 
> (first use in this function); did you mean 'n_rcu_scale_writer_finished'?
>   431 |if (atomic_inc_return(_rcu_perf_writer_finished) >=
>   |   ^~
>   |   n_rcu_scale_writer_finished
> 
> Caused by commit
> 
>   a20b5bd09813 ("rcuperf: Change rcuperf to rcuscale")
> 
> I have used the rcu tree from next-20200817 for today.

My test scripts clearly are not dealing gracefully with filename changes,
are they?  :-/

Thank you for catching this one!  I have queued a fix.

Thanx, Paul

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

[Paul E. McKenney]

On Thu, Jun 25, 2020 at 12:57:53PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_enter':
> kernel/rcu/tree.c:251:8: error: implicit declaration of function 
> 'arch_atomic_add_return'; did you mean 'atomic_add_return'? 
> [-Werror=implicit-function-declaration]
>   251 |  seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
>   |^~
>   |atomic_add_return
> kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_exit':
> kernel/rcu/tree.c:281:3: error: implicit declaration of function 
> 'arch_atomic_andnot'; did you mean 'atomic_andnot'? 
> [-Werror=implicit-function-declaration]
>   281 |   arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
>   |   ^~
>   |   atomic_andnot
> kernel/rcu/tree.c: In function 'rcu_dynticks_curr_cpu_in_eqs':
> kernel/rcu/tree.c:314:11: error: implicit declaration of function 
> 'arch_atomic_read'; did you mean 'atomic_read'? 
> [-Werror=implicit-function-declaration]
>   314 |  return !(arch_atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
>   |   ^~~~
>   |   atomic_read
> 
> Caused by commit
> 
>   d2f8491368e5 ("rcu: Fixup noinstr warnings")
> 
> I reverted that commit for today.

MIPS doesn't much like it, either.  I hope to get an update tomorrow.

Apologies for the hassle!

Thanx, Paul

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

[Paul E. McKenney]

On Thu, May 28, 2020 at 09:33:59AM -0700, Paul E. McKenney wrote:
> On Thu, May 28, 2020 at 07:05:01PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the rcu tree, today's linux-next build (powercp
> > allyesconfig) failed like this:
> > 
> > ld: kernel/rcu/refperf.o:(.discard+0x0): multiple definition of 
> > `__pcpu_unique_srcu_ctl_perf_srcu_data'; 
> > kernel/rcu/rcuperf.o:(.discard+0x0): first defined here
> > 
> > Caused by commit
> > 
> >   786a25497743 ("refperf: Add a test to measure performance of read-side 
> > synchronization")
> > 
> > From srcutree.h:
> > 
> >  * 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.
> > 
> > I have applied the following patch for today.
> 
> I have a patch queued, but it is currently blocked by other broken
> commits which I expect to have straightened out today.
> 
> Yet again, please accept my apologies for the hassle!

And this is now in rcu/next.

Thanx, Paul

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

[Paul E. McKenney]

On Thu, May 28, 2020 at 07:05:01PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (powercp
> allyesconfig) failed like this:
> 
> ld: kernel/rcu/refperf.o:(.discard+0x0): multiple definition of 
> `__pcpu_unique_srcu_ctl_perf_srcu_data'; kernel/rcu/rcuperf.o:(.discard+0x0): 
> first defined here
> 
> Caused by commit
> 
>   786a25497743 ("refperf: Add a test to measure performance of read-side 
> synchronization")
> 
> From srcutree.h:
> 
>  * 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.
> 
> I have applied the following patch for today.

I have a patch queued, but it is currently blocked by other broken
commits which I expect to have straightened out today.

Yet again, please accept my apologies for the hassle!

Thanx, Paul

> From: Stephen Rothwell 
> Date: Thu, 28 May 2020 18:57:17 +1000
> Subject: [PATCH] refperf: uniqify name
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  kernel/rcu/refperf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/rcu/refperf.c b/kernel/rcu/refperf.c
> index 8c4a63257be9..47df72c492b3 100644
> --- a/kernel/rcu/refperf.c
> +++ b/kernel/rcu/refperf.c
> @@ -133,8 +133,8 @@ static struct ref_perf_ops rcu_ops = {
>  
>  
>  // Definitions for SRCU ref perf testing.
> -DEFINE_STATIC_SRCU(srcu_ctl_perf);
> -static struct srcu_struct *srcu_ctlp = _ctl_perf;
> +DEFINE_STATIC_SRCU(ref_srcu_ctl_perf);
> +static struct srcu_struct *srcu_ctlp = _srcu_ctl_perf;
>  
>  static void srcu_ref_perf_read_section(int nloops)
>  {
> -- 
> 2.26.2
> 
> -- 
> Cheers,
> Stephen Rothwell

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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"  
> wrote:
> >
> > Huh.  "It has been building fine for me."  I added
> > 
> > #include 
> > #include 
> > 
> > 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 
> Date: Tue, 13 Aug 2019 15:12:00 +1000
> Subject: [PATCH] rcu: use the correct includes
> 
> Signed-off-by: Stephen Rothwell 

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 
> -#include 
> +#include 
> +#include 
>  
>  /* Simple unsegmented callback lists. */
>  struct rcu_cblist {
> -- 
> 2.20.1
> 
> -- 
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

On Mon, 12 Aug 2019 09:19:34 -0700 "Paul E. McKenney"  
wrote:
>
> Huh.  "It has been building fine for me."  I added
> 
>   #include 
>   #include 
> 
> 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 
Date: Tue, 13 Aug 2019 15:12:00 +1000
Subject: [PATCH] rcu: use the correct includes

Signed-off-by: Stephen Rothwell 
---
 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 
-#include 
+#include 
+#include 
 
 /* Simple unsegmented callback lists. */
 struct rcu_cblist {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


pgpTTguUASQMl.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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 :
> 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 
#include 

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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(>pi_lock);
>   spin_unlock(>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 
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 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: Alan Stern 
Cc: Andrea Parri 
Cc: Linus Torvalds 
[ paulmck: Drop smp_mb() based on Peter Zijlstra's analysis:
  
http://lkml.kernel.org/r/20170811144150.26gowhxte7ri5...@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(>pi_lock);
+   raw_spin_lock_irq(>pi_lock);
+   raw_spin_unlock_irq(>pi_lock);
 
/* Causes final put_task_struct in finish_task_switch(): */
__set_current_state(TASK_DEAD);

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

[Paul E. McKenney]

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(>pi_lock);
>   spin_unlock(>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 
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 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: Alan Stern 
Cc: Andrea Parri 
Cc: Linus Torvalds 
[ paulmck: Drop smp_mb() based on Peter Zijlstra's analysis:
  
http://lkml.kernel.org/r/20170811144150.26gowhxte7ri5...@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(>pi_lock);
+   raw_spin_lock_irq(>pi_lock);
+   raw_spin_unlock_irq(>pi_lock);
 
/* Causes final put_task_struct in finish_task_switch(): */
__set_current_state(TASK_DEAD);

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

[Peter Zijlstra]

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:

CPU0CPU1

p->state = TASK_UNINTERRUPTIBLE;
 try_to_wake_up(p)
p->state = TASK_RUNNING
spin_lock(>pi_lock);
spin_unlock(>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.

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

[Peter Zijlstra]

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:

CPU0CPU1

p->state = TASK_UNINTERRUPTIBLE;
 try_to_wake_up(p)
p->state = TASK_RUNNING
spin_lock(>pi_lock);
spin_unlock(>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.

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

[Peter Zijlstra]

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(>pi_lock);
  spin_unlock(>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.

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

[Peter Zijlstra]

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(>pi_lock);
  spin_unlock(>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.

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Peter Zijlstra]

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.

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

[Peter Zijlstra]

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.

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

[Paul E. McKenney]

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 
> 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 
> ---
>  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(>pi_lock);
>   raw_spin_unlock_irq(>pi_lock);
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

[Paul E. McKenney]

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 
> 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 
> ---
>  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(>pi_lock);
>   raw_spin_unlock_irq(>pi_lock);
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

[Paul E. McKenney]

On Tue, May 30, 2017 at 02:10:26PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney"  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 
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 
Signed-off-by: Paul E. McKenney 

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 
 #include 
 #include 
@@ -16,6 +14,11 @@
 #include 
 #include 
 
+#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 

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

[Paul E. McKenney]

On Tue, May 30, 2017 at 02:10:26PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney"  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 
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 
Signed-off-by: Paul E. McKenney 

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 
 #include 
 #include 
@@ -16,6 +14,11 @@
 #include 
 #include 
 
+#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);
  

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

[Michael Ellerman]

"Paul E. McKenney"  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

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

[Michael Ellerman]

"Paul E. McKenney"  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

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

[Stephen Rothwell]

Hi Joe,

On Mon, 29 May 2017 19:20:25 -0700 Joe Perches  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" 
> > > > >  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 

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Joe,

On Mon, 29 May 2017 19:20:25 -0700 Joe Perches  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" 
> > > > >  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 

-- 
Cheers,
Stephen Rothwell

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

[Joe Perches]

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

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

[Joe Perches]

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

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

[Paul E. McKenney]

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" 
> > >  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 
>  #include 
>  #include 
> @@ -16,6 +14,11 @@
>  #include 
>  #include 
>  
> +#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 

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

[Paul E. McKenney]

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" 
> > >  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 
>  #include 
>  #include 
> @@ -16,6 +14,11 @@
>  #include 
>  #include 
>  
> +#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");
> 

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

[Joe Perches]

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" 
> >  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 
 #include 
 #include 
@@ -16,6 +14,11 @@
 #include 
 #include 
 
+#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);
    

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

[Joe Perches]

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" 
> >  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 
 #include 
 #include 
@@ -16,6 +14,11 @@
 #include 
 #include 
 
+#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;
   

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

[Stephen Rothwell]

Hi Paul,

On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" 
 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 
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 
---
 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 
 #include 
@@ -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) {
-   

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

[Stephen Rothwell]

Hi Paul,

On Mon, 29 May 2017 14:15:05 -0700 "Paul E. McKenney" 
 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 
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 
---
 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 
 #include 
@@ -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");
+   

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range 
> (0x9d88 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:619: Error: operand out of range 
> (0x9dc0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:643: Error: operand out of range 
> (0x9df8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:650: Error: operand out of range 
> (0x9d8c is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1353: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1663: Error: operand out of range 
> (0x9db0 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1665: Error: operand out of range 
> (0x9dc8 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1734: Error: operand out of range 
> (0x9db8 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1782: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1837: Error: operand out of range 
> (0x9de0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1877: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1918: Error: operand out of range 
> (0x9de0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1943: Error: operand out of range 
> (0xa048 is not between 0x8000 and 0x7ffc)
> 
> 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

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

[Paul E. McKenney]

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 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range 
> (0x9d88 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:619: Error: operand out of range 
> (0x9dc0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:643: Error: operand out of range 
> (0x9df8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:650: Error: operand out of range 
> (0x9d8c is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1353: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1663: Error: operand out of range 
> (0x9db0 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1665: Error: operand out of range 
> (0x9dc8 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1734: Error: operand out of range 
> (0x9db8 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1782: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1837: Error: operand out of range 
> (0x9de0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1877: Error: operand out of range 
> (0x9ff8 is not between 0x8000 and 0x7fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1918: Error: operand out of range 
> (0x9de0 is not between 0x8000 and 0x7ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1943: Error: operand out of range 
> (0xa048 is not between 0x8000 and 0x7ffc)
> 
> 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

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

[Stephen Rothwell]

Hi Paul,

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

What I live for :-)

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

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

What I live for :-)

-- 
Cheers,
Stephen Rothwell

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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  
> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
> >  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

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

[Paul E. McKenney]

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  
> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
> >  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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Daniel Vetter]

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

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

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

[Daniel Vetter]

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

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

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

[Paul E. McKenney]

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  
> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
> >  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

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

[Paul E. McKenney]

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  
> wrote:
> >
> > On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
> >  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

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

[Stephen Rothwell]

Hi Paul,

On Mon, 13 Feb 2017 17:43:24 +1100 Stephen Rothwell  
wrote:
>
> On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
>  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

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

[Stephen Rothwell]

Hi Paul,

On Mon, 13 Feb 2017 17:43:24 +1100 Stephen Rothwell  
wrote:
>
> On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
>  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

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

[Stephen Rothwell]

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
 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

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

[Stephen Rothwell]

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
 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

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

[Paul E. McKenney]

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  wrote:
> >
> > On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  
> > 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

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

[Paul E. McKenney]

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  wrote:
> >
> > On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  
> > 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

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

[Stephen Rothwell]

Hi Paul,

On Thu, 19 Jan 2017 13:54:37 -0800 Paul McKenney  wrote:
>
> On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  
> 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

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

[Stephen Rothwell]

Hi Paul,

On Thu, 19 Jan 2017 13:54:37 -0800 Paul McKenney  wrote:
>
> On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  
> 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

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

[Paul McKenney]

On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  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 
> 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 
> ---
>  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 = _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

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

[Paul McKenney]

On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  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 
> 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 
> ---
>  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 = _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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

On Wed, Sep 02, 2015 at 09:29:18AM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  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 

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 
Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney 
Acked-by: Ingo Molnar 

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)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney  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 

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 
> Reported-by: Stephen Rothwell 
> Cc: Ingo Molnar 
> ---
>  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
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Davidlohr Bueso]

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 
Reported-by: Stephen Rothwell 
Cc: Ingo Molnar 
---
 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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Davidlohr Bueso]

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 
Reported-by: Stephen Rothwell 
Cc: Ingo Molnar 
---
 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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney  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 

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

On Wed, Sep 02, 2015 at 09:29:18AM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  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 

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 
Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney 
Acked-by: Ingo Molnar 

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)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 
> Reported-by: Stephen Rothwell 
> Cc: Ingo Molnar 
> ---
>  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
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Paul,

On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney" 
 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Paul,

On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney" 
 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney  wrote:

> On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  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 

Thank you!

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney  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 

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

On Fri, Jul 17, 2015 at 01:40:46PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Paul E. McKenney paul...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

On Fri, Jul 17, 2015 at 01:40:46PM +0200, Ingo Molnar wrote:
 
 * Paul E. McKenney paul...@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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 paul...@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)
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/