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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgplAYHVyadYZ.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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

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

-- 
Cheers,
Stephen Rothwell


pgpId1kqzfuPh.pgp
Description: OpenPGP digital signature

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.

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

[Stephen Rothwell]

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 
---
 mm/slab.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/mm/slab.c b/mm/slab.c
index 1f3b263f81ee..064707ac9f54 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3650,6 +3650,11 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t 
flags,
return __do_kmalloc_node(size, flags, node, caller);
 }
 EXPORT_SYMBOL(__kmalloc_node_track_caller);
+#else
+void *kmem_cache_last_alloc(struct kmem_cache *cachep, void *object)
+{
+   return NULL;
+}
 #endif /* CONFIG_NUMA */
 
 /**
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell


pgpJ5u6WWAzbj.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpmzEy0j4Tet.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpBJnn723mXz.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpcn5IwHeT9K.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpSc0j4xzjdu.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

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


pgpnAfBhji0Jz.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpIgM6nz6Gwp.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi all,

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

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

Caused by commit

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

Also:

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

Caused by commits:

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

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

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

-- 
Cheers,
Stephen Rothwell


pgpFCvEx3bbUt.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

-- 
Cheers,
Stephen Rothwell

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
> 

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

Interacting with commit

  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

from the tip tree.

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

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

Interacting with commit

  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

from the tip tree.

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

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

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

added by commit

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

before v2.6.39-rc2 ...

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

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

added by commit

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

before v2.6.39-rc2 ...

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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.

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

[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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

interacting with commit

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

from the drm-intel tree.

I added the following merge fix patch:

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

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

interacting with commit

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

from the drm-intel tree.

I added the following merge fix patch:

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

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

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

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

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

[Stephen Rothwell]

Hi Paul,

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

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

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

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

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