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

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

Hi Paul,

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

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

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

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

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

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

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

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

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

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

So here's a fix ontop.

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

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

-- 
Regards/Gruss,
    Boris.

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

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

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


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

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

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

Thanks,

	Ingo

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

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

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

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

Thank you all, and apologies for the hassle!

							Thanx, Paul


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

* Re: linux-next: build failure after merge of the rcu tree
  2024-01-24 13:31     ` Jiri Wiesner
@ 2024-01-24 14:20       ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2024-01-24 14:20 UTC (permalink / raw)
  To: Jiri Wiesner
  Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 02:31:05PM +0100, Jiri Wiesner wrote:
> On Wed, Jan 24, 2024 at 04:12:23AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 24, 2024 at 10:49:54AM +0100, Jiri Wiesner wrote:
> > > On Wed, Jan 24, 2024 at 03:17:43PM +1100, Stephen Rothwell wrote:
> > > > After merging the rcu tree, today's linux-next build (i386 defconfig)
> > > > failed like this:
> > > > In file included from include/linux/dev_printk.h:14,
> > > >                  from include/linux/device.h:15,
> > > >                  from kernel/time/clocksource.c:10:
> > > > kernel/time/clocksource.c: In function 'clocksource_watchdog':
> > > > kernel/time/clocksource.c:103:34: error: integer overflow in expression of type 'long int' results in '-1619276800' [-Werror=overflow]
> > > >   103 |                                  * NSEC_PER_SEC / HZ)
> > > >       |                                  ^
> > > > Caused by commit
> > > >   1a4545025600 ("clocksource: Skip watchdog check for large watchdog intervals")
> > > > I have used the rcu tree from next-20240123 for today.
> > > 
> > > This particular patch is still beging discussed on the LKML. This is the 
> > > latest submission with improved variable naming, increased threshold and 
> > > changes to the log and the warning message (as proposed by tglx):
> > > https://lore.kernel.org/lkml/20240122172350.GA740@incl/
> > > Especially the change to the message is important. I think this message 
> > > will be commonplace on 8 NUMA node (and larger) machines. If there is 
> > > anything else I can do to assist please let me know.
> > 
> > Here is the offending #define:
> > 
> > #define WATCHDOG_INTR_MAX_NS	((WATCHDOG_INTERVAL + (WATCHDOG_INTERVAL >> 1))\
> > 				 * NSEC_PER_SEC / HZ)
> > 
> > The problem is that these things are int or long, and on i386, that
> > is only 32 bits.  NSEC_PER_SEC is one billion, and WATCHDOG_INTERVAL
> > is often 1000, which overflows.  The division by HZ gets this back in
> > range at about 1.5x10^9.
> 
> Exactly.
> 
> > So this computation must be done in 64 bits even on 32-bit systems.
> > My thought would be a cast to u64, then back to long for the result.
> 
> This will be a more precise solution than enclosing NSEC_PER_SEC / HZ in 
> brackets, which I chose to do in the v2 of this patch.
> 
> > Whatever approach, Jiri, would you like to send an updated patch?
> 
> Yes, I can incorporate the casting to u64 and back to long into the patch. 
> At this point, I am not sure which version to use. There are:
> * v1 (submitted to the LKML on Jan 3rd): the patch that got merged into linux-next
> * v2 (submitted to the LKML on Jan 10th): that has an alternative fix for the interger overflow
> * v3 (submitted to the LKML on Jan 22nd): that incoporates suggestions by Thomas Gleixner
> 
> I could update the v3 of this patch with casting to u64 and back to long. 
> WATCHDOG_INTERVAL_MAX_NS got set to 2 * WATCHDOG_INTERVAL in v3 - a change 
> I do not entirely agree with. I think WATCHDOG_INTERVAL_MAX_NS should be 
> kept narrow so as not to impose a limit on time skew that is too strict 
> for readout intervals approaching 2 * WATCHDOG_INTERVAL in their length. 
> The question is what is too strict.

Please accept my apologies!  I should have caught your updates.

I will drop my current version of your patch and queue your v3 for review
and testing.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2024-01-24 12:12   ` Paul E. McKenney
@ 2024-01-24 13:31     ` Jiri Wiesner
  2024-01-24 14:20       ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Jiri Wiesner @ 2024-01-24 13:31 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 04:12:23AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 24, 2024 at 10:49:54AM +0100, Jiri Wiesner wrote:
> > On Wed, Jan 24, 2024 at 03:17:43PM +1100, Stephen Rothwell wrote:
> > > After merging the rcu tree, today's linux-next build (i386 defconfig)
> > > failed like this:
> > > In file included from include/linux/dev_printk.h:14,
> > >                  from include/linux/device.h:15,
> > >                  from kernel/time/clocksource.c:10:
> > > kernel/time/clocksource.c: In function 'clocksource_watchdog':
> > > kernel/time/clocksource.c:103:34: error: integer overflow in expression of type 'long int' results in '-1619276800' [-Werror=overflow]
> > >   103 |                                  * NSEC_PER_SEC / HZ)
> > >       |                                  ^
> > > Caused by commit
> > >   1a4545025600 ("clocksource: Skip watchdog check for large watchdog intervals")
> > > I have used the rcu tree from next-20240123 for today.
> > 
> > This particular patch is still beging discussed on the LKML. This is the 
> > latest submission with improved variable naming, increased threshold and 
> > changes to the log and the warning message (as proposed by tglx):
> > https://lore.kernel.org/lkml/20240122172350.GA740@incl/
> > Especially the change to the message is important. I think this message 
> > will be commonplace on 8 NUMA node (and larger) machines. If there is 
> > anything else I can do to assist please let me know.
> 
> Here is the offending #define:
> 
> #define WATCHDOG_INTR_MAX_NS	((WATCHDOG_INTERVAL + (WATCHDOG_INTERVAL >> 1))\
> 				 * NSEC_PER_SEC / HZ)
> 
> The problem is that these things are int or long, and on i386, that
> is only 32 bits.  NSEC_PER_SEC is one billion, and WATCHDOG_INTERVAL
> is often 1000, which overflows.  The division by HZ gets this back in
> range at about 1.5x10^9.

Exactly.

> So this computation must be done in 64 bits even on 32-bit systems.
> My thought would be a cast to u64, then back to long for the result.

This will be a more precise solution than enclosing NSEC_PER_SEC / HZ in 
brackets, which I chose to do in the v2 of this patch.

> Whatever approach, Jiri, would you like to send an updated patch?

Yes, I can incorporate the casting to u64 and back to long into the patch. 
At this point, I am not sure which version to use. There are:
* v1 (submitted to the LKML on Jan 3rd): the patch that got merged into linux-next
* v2 (submitted to the LKML on Jan 10th): that has an alternative fix for the interger overflow
* v3 (submitted to the LKML on Jan 22nd): that incoporates suggestions by Thomas Gleixner

I could update the v3 of this patch with casting to u64 and back to long. 
WATCHDOG_INTERVAL_MAX_NS got set to 2 * WATCHDOG_INTERVAL in v3 - a change 
I do not entirely agree with. I think WATCHDOG_INTERVAL_MAX_NS should be 
kept narrow so as not to impose a limit on time skew that is too strict 
for readout intervals approaching 2 * WATCHDOG_INTERVAL in their length. 
The question is what is too strict.
-- 
Jiri Wiesner
SUSE Labs

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

* Re: linux-next: build failure after merge of the rcu tree
  2024-01-24  9:49 ` Jiri Wiesner
@ 2024-01-24 12:12   ` Paul E. McKenney
  2024-01-24 13:31     ` Jiri Wiesner
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2024-01-24 12:12 UTC (permalink / raw)
  To: Jiri Wiesner
  Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 10:49:54AM +0100, Jiri Wiesner wrote:
> On Wed, Jan 24, 2024 at 03:17:43PM +1100, Stephen Rothwell wrote:
> > After merging the rcu tree, today's linux-next build (i386 defconfig)
> > failed like this:
> > In file included from include/linux/dev_printk.h:14,
> >                  from include/linux/device.h:15,
> >                  from kernel/time/clocksource.c:10:
> > kernel/time/clocksource.c: In function 'clocksource_watchdog':
> > kernel/time/clocksource.c:103:34: error: integer overflow in expression of type 'long int' results in '-1619276800' [-Werror=overflow]
> >   103 |                                  * NSEC_PER_SEC / HZ)
> >       |                                  ^
> > Caused by commit
> >   1a4545025600 ("clocksource: Skip watchdog check for large watchdog intervals")
> > I have used the rcu tree from next-20240123 for today.
> 
> This particular patch is still beging discussed on the LKML. This is the 
> latest submission with improved variable naming, increased threshold and 
> changes to the log and the warning message (as proposed by tglx):
> https://lore.kernel.org/lkml/20240122172350.GA740@incl/
> Especially the change to the message is important. I think this message 
> will be commonplace on 8 NUMA node (and larger) machines. If there is 
> anything else I can do to assist please let me know.

Here is the offending #define:

#define WATCHDOG_INTR_MAX_NS	((WATCHDOG_INTERVAL + (WATCHDOG_INTERVAL >> 1))\
				 * NSEC_PER_SEC / HZ)

The problem is that these things are int or long, and on i386, that
is only 32 bits.  NSEC_PER_SEC is one billion, and WATCHDOG_INTERVAL
is often 1000, which overflows.  The division by HZ gets this back in
range at about 1.5x10^9.

So this computation must be done in 64 bits even on 32-bit systems.
My thought would be a cast to u64, then back to long for the result.

Whatever approach, Jiri, would you like to send an updated patch?

In the meantime, I will rebase to exclude this one from -next.

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2024-01-24  4:17 Stephen Rothwell
@ 2024-01-24  9:49 ` Jiri Wiesner
  2024-01-24 12:12   ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Jiri Wiesner @ 2024-01-24  9:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul E. McKenney, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 03:17:43PM +1100, Stephen Rothwell wrote:
> After merging the rcu tree, today's linux-next build (i386 defconfig)
> failed like this:
> In file included from include/linux/dev_printk.h:14,
>                  from include/linux/device.h:15,
>                  from kernel/time/clocksource.c:10:
> kernel/time/clocksource.c: In function 'clocksource_watchdog':
> kernel/time/clocksource.c:103:34: error: integer overflow in expression of type 'long int' results in '-1619276800' [-Werror=overflow]
>   103 |                                  * NSEC_PER_SEC / HZ)
>       |                                  ^
> Caused by commit
>   1a4545025600 ("clocksource: Skip watchdog check for large watchdog intervals")
> I have used the rcu tree from next-20240123 for today.

This particular patch is still beging discussed on the LKML. This is the 
latest submission with improved variable naming, increased threshold and 
changes to the log and the warning message (as proposed by tglx):
https://lore.kernel.org/lkml/20240122172350.GA740@incl/
Especially the change to the message is important. I think this message 
will be commonplace on 8 NUMA node (and larger) machines. If there is 
anything else I can do to assist please let me know.
-- 
Jiri Wiesner
SUSE Labs

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

* linux-next: build failure after merge of the rcu tree
@ 2024-01-24  4:17 Stephen Rothwell
  2024-01-24  9:49 ` Jiri Wiesner
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2024-01-24  4:17 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Jiri Wiesner, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

In file included from include/linux/dev_printk.h:14,
                 from include/linux/device.h:15,
                 from kernel/time/clocksource.c:10:
kernel/time/clocksource.c: In function 'clocksource_watchdog':
kernel/time/clocksource.c:103:34: error: integer overflow in expression of type 'long int' results in '-1619276800' [-Werror=overflow]
  103 |                                  * NSEC_PER_SEC / HZ)
      |                                  ^
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
   77 | # define unlikely(x)    __builtin_expect(!!(x), 0)
      |                                             ^
kernel/time/clocksource.c:486:41: note: in expansion of macro 'WATCHDOG_INTR_MAX_NS'
  486 |                 if (unlikely(interval > WATCHDOG_INTR_MAX_NS)) {
      |                                         ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  1a4545025600 ("clocksource: Skip watchdog check for large watchdog intervals")

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2023-07-27  4:19 Stephen Rothwell
@ 2023-07-27 14:08 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2023-07-27 14:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Jul 27, 2023 at 02:19:30PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (arm64 defconfig)
> failed like this:
> 
> In file included from arch/arm64/include/asm/alternative.h:9,
>                  from arch/arm64/include/asm/lse.h:14,
>                  from arch/arm64/include/asm/cmpxchg.h:14,
>                  from arch/arm64/include/asm/atomic.h:16,
>                  from include/linux/atomic.h:7,
>                  from include/asm-generic/bitops/atomic.h:5,
>                  from arch/arm64/include/asm/bitops.h:25,
>                  from include/linux/bitops.h:68,
>                  from arch/arm64/include/asm/cache.h:40,
>                  from include/linux/cache.h:6,
>                  from include/linux/slab.h:15,
>                  from include/linux/resource_ext.h:11,
>                  from include/linux/acpi.h:13,
>                  from include/acpi/apei.h:9,
>                  from include/acpi/ghes.h:5,
>                  from include/linux/arm_sdei.h:8,
>                  from arch/arm64/kernel/asm-offsets.c:10:
> include/linux/init.h:149:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
>   149 | extern char boot_command_line[] __ro_after_init;
>       |                                 ^~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   de2f542cfbec ("fs/proc: Add /proc/cmdline_load for boot loader arguments")
> 
> I have applied the following fix up (I have a faint memory that the
> section setting attributes are only needed on the definition, not the
> declaration):
> 
> From 9f56e539ed7d9c402caa85d4f5f3f8cec8373b2f Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 27 Jul 2023 13:26:08 +1000
> Subject: [PATCH] fix up for "fs/proc: Add /proc/cmdline_load for boot loader
>  arguments"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thank you, Stephen, I will adjust the commit as shown below.

							Thanx, Paul

> ---
>  include/linux/init.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/include/linux/init.h b/include/linux/init.h
> index e3ce68988e1b..c075983c5015 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -113,8 +113,6 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#include <linux/cache.h>
> -
>  /*
>   * Used for initialization calls..
>   */
> @@ -146,7 +144,7 @@ struct file_system_type;
>  
>  /* Defined in init/main.c */
>  extern int do_one_initcall(initcall_t fn);
> -extern char boot_command_line[] __ro_after_init;
> +extern char boot_command_line[];
>  extern char *saved_command_line;
>  extern unsigned int saved_command_line_len;
>  extern unsigned int reset_devices;
> -- 
> 2.40.1
> 
> -- 
> Cheers,
> Stephen Rothwell



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

* linux-next: build failure after merge of the rcu tree
@ 2023-07-27  4:19 Stephen Rothwell
  2023-07-27 14:08 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2023-07-27  4:19 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

In file included from arch/arm64/include/asm/alternative.h:9,
                 from arch/arm64/include/asm/lse.h:14,
                 from arch/arm64/include/asm/cmpxchg.h:14,
                 from arch/arm64/include/asm/atomic.h:16,
                 from include/linux/atomic.h:7,
                 from include/asm-generic/bitops/atomic.h:5,
                 from arch/arm64/include/asm/bitops.h:25,
                 from include/linux/bitops.h:68,
                 from arch/arm64/include/asm/cache.h:40,
                 from include/linux/cache.h:6,
                 from include/linux/slab.h:15,
                 from include/linux/resource_ext.h:11,
                 from include/linux/acpi.h:13,
                 from include/acpi/apei.h:9,
                 from include/acpi/ghes.h:5,
                 from include/linux/arm_sdei.h:8,
                 from arch/arm64/kernel/asm-offsets.c:10:
include/linux/init.h:149:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
  149 | extern char boot_command_line[] __ro_after_init;
      |                                 ^~~~~~~~~~~~~~~

Caused by commit

  de2f542cfbec ("fs/proc: Add /proc/cmdline_load for boot loader arguments")

I have applied the following fix up (I have a faint memory that the
section setting attributes are only needed on the definition, not the
declaration):

From 9f56e539ed7d9c402caa85d4f5f3f8cec8373b2f Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 27 Jul 2023 13:26:08 +1000
Subject: [PATCH] fix up for "fs/proc: Add /proc/cmdline_load for boot loader
 arguments"

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

diff --git a/include/linux/init.h b/include/linux/init.h
index e3ce68988e1b..c075983c5015 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -113,8 +113,6 @@
 
 #ifndef __ASSEMBLY__
 
-#include <linux/cache.h>
-
 /*
  * Used for initialization calls..
  */
@@ -146,7 +144,7 @@ struct file_system_type;
 
 /* Defined in init/main.c */
 extern int do_one_initcall(initcall_t fn);
-extern char boot_command_line[] __ro_after_init;
+extern char boot_command_line[];
 extern char *saved_command_line;
 extern unsigned int saved_command_line_len;
 extern unsigned int reset_devices;
-- 
2.40.1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2023-05-22  1:45   ` Stephen Rothwell
@ 2023-05-22 14:57     ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2023-05-22 14:57 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Mon, May 22, 2023 at 11:45:03AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 18 May 2023 19:12:52 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >
> > On Fri, May 19, 2023 at 10:59:50AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > kernel/rcu/rcuscale.c:340:27: error: 'get_rcu_tasks_trace_gp_kthread' undeclared here (not in a function); did you mean 'show_rcu_tasks_trace_gp_kthread'?
> > >   340 |         .rso_gp_kthread = get_rcu_tasks_trace_gp_kthread,
> > >       |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >       |                           show_rcu_tasks_trace_gp_kthread
> > > 
> > > Caused by commit
> > > 
> > >   9bb839a83e1b ("rcuscale: Measure grace-period kthread CPU time")
> > > 
> > > CONFIG_RCU_SCALE_TEST=m
> > > 
> > > I have used the rcu tree from next-20230518 for today.  
> > 
> > Huh.  Modules and #ifdefs trip me up again.  Will fix, and thank you
> > for catching it!
> 
> This is now:
> 
> ERROR: modpost: "get_rcu_tasks_trace_gp_kthread" [kernel/rcu/rcuscale.ko] undefined!
> 
> I have used the rcu tree from next-20230518 again for today.

-ENOREPRODUCE

Perhaps the #ifdef around its definition is causing trouble in your
environment.  And to be fair, the small-memory systems that might not
want that function unconditionally defined could do even better by not
configuring anything requiring Tasks Trace RCU.

I will adjust.  Here is hoping!

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2023-05-19  2:12 ` Paul E. McKenney
@ 2023-05-22  1:45   ` Stephen Rothwell
  2023-05-22 14:57     ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2023-05-22  1:45 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Paul,

On Thu, 18 May 2023 19:12:52 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> On Fri, May 19, 2023 at 10:59:50AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > kernel/rcu/rcuscale.c:340:27: error: 'get_rcu_tasks_trace_gp_kthread' undeclared here (not in a function); did you mean 'show_rcu_tasks_trace_gp_kthread'?
> >   340 |         .rso_gp_kthread = get_rcu_tasks_trace_gp_kthread,
> >       |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >       |                           show_rcu_tasks_trace_gp_kthread
> > 
> > Caused by commit
> > 
> >   9bb839a83e1b ("rcuscale: Measure grace-period kthread CPU time")
> > 
> > CONFIG_RCU_SCALE_TEST=m
> > 
> > I have used the rcu tree from next-20230518 for today.  
> 
> Huh.  Modules and #ifdefs trip me up again.  Will fix, and thank you
> for catching it!

This is now:

ERROR: modpost: "get_rcu_tasks_trace_gp_kthread" [kernel/rcu/rcuscale.ko] undefined!

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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2023-05-19  0:59 Stephen Rothwell
@ 2023-05-19  2:12 ` Paul E. McKenney
  2023-05-22  1:45   ` Stephen Rothwell
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2023-05-19  2:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Fri, May 19, 2023 at 10:59:50AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> kernel/rcu/rcuscale.c:340:27: error: 'get_rcu_tasks_trace_gp_kthread' undeclared here (not in a function); did you mean 'show_rcu_tasks_trace_gp_kthread'?
>   340 |         .rso_gp_kthread = get_rcu_tasks_trace_gp_kthread,
>       |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                           show_rcu_tasks_trace_gp_kthread
> 
> Caused by commit
> 
>   9bb839a83e1b ("rcuscale: Measure grace-period kthread CPU time")
> 
> CONFIG_RCU_SCALE_TEST=m
> 
> I have used the rcu tree from next-20230518 for today.

Huh.  Modules and #ifdefs trip me up again.  Will fix, and thank you
for catching it!

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2023-05-19  0:59 Stephen Rothwell
  2023-05-19  2:12 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2023-05-19  0:59 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

kernel/rcu/rcuscale.c:340:27: error: 'get_rcu_tasks_trace_gp_kthread' undeclared here (not in a function); did you mean 'show_rcu_tasks_trace_gp_kthread'?
  340 |         .rso_gp_kthread = get_rcu_tasks_trace_gp_kthread,
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                           show_rcu_tasks_trace_gp_kthread

Caused by commit

  9bb839a83e1b ("rcuscale: Measure grace-period kthread CPU time")

CONFIG_RCU_SCALE_TEST=m

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2023-03-14  1:29 Stephen Rothwell
@ 2023-03-14  4:43 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2023-03-14  4:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Uladzislau Rezki (Sony),
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Mar 14, 2023 at 12:29:22PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/mac802154/scan.c: In function 'mac802154_scan_cleanup_locked':
> net/mac802154/scan.c:55:26: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
>    55 |         kfree_rcu(request);
>       |                          ^
> In file included from include/linux/rbtree.h:24,
>                  from include/linux/mm_types.h:11,
>                  from include/linux/buildid.h:5,
>                  from include/linux/module.h:14,
>                  from net/mac802154/scan.c:11:
> include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
>   984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
>       | 
> net/mac802154/scan.c:55:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
>    55 |         kfree_rcu(request);
>       |         ^~~~~~~~~
>       |         kfree_skb
> net/mac802154/scan.c:55:9: note: each undeclared identifier is reported only once for each function it appears in
> net/mac802154/scan.c: In function 'mac802154_stop_beacons_locked':
> net/mac802154/scan.c:406:26: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
>   406 |         kfree_rcu(request);
>       |                          ^
> include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
>   984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
>       | 
> net/mac802154/scan.c:406:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
>   406 |         kfree_rcu(request);
>       |         ^~~~~~~~~
>       |         kfree_skb
> drivers/infiniband/sw/rxe/rxe_mr.c: In function 'rxe_dereg_mr':
> drivers/infiniband/sw/rxe/rxe_mr.c:734:21: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
>   734 |         kfree_rcu(mr);
>       |                     ^
> In file included from include/linux/rculist.h:11,
>                  from include/linux/dcache.h:8,
>                  from include/linux/fs.h:8,
>                  from include/linux/highmem.h:5,
>                  from include/linux/bvec.h:10,
>                  from include/linux/blk_types.h:10,
>                  from include/linux/bio.h:10,
>                  from include/linux/libnvdimm.h:14,
>                  from drivers/infiniband/sw/rxe/rxe_mr.c:7:
> include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
>   984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
>       | 
> drivers/infiniband/sw/rxe/rxe_mr.c:734:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
>   734 |         kfree_rcu(mr);
>       |         ^~~~~~~~~
>       |         kfree_skb
> drivers/infiniband/sw/rxe/rxe_mr.c:734:9: note: each undeclared identifier is reported only once for each function it appears in
> 
> Caused by commit
> 
>   62a2ac23b35f ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")
> 
> I have used the rcu tree from next-20230310 for today.

Please accept my apologies -- I left out that revert.  I have pushed
out an rcu/next including it.

But I guess we now know for sure that this revert is still needed.  :-/

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2023-03-14  1:29 Stephen Rothwell
  2023-03-14  4:43 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2023-03-14  1:29 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Uladzislau Rezki (Sony),
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

net/mac802154/scan.c: In function 'mac802154_scan_cleanup_locked':
net/mac802154/scan.c:55:26: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
   55 |         kfree_rcu(request);
      |                          ^
In file included from include/linux/rbtree.h:24,
                 from include/linux/mm_types.h:11,
                 from include/linux/buildid.h:5,
                 from include/linux/module.h:14,
                 from net/mac802154/scan.c:11:
include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
  984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
      | 
net/mac802154/scan.c:55:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
   55 |         kfree_rcu(request);
      |         ^~~~~~~~~
      |         kfree_skb
net/mac802154/scan.c:55:9: note: each undeclared identifier is reported only once for each function it appears in
net/mac802154/scan.c: In function 'mac802154_stop_beacons_locked':
net/mac802154/scan.c:406:26: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
  406 |         kfree_rcu(request);
      |                          ^
include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
  984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
      | 
net/mac802154/scan.c:406:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
  406 |         kfree_rcu(request);
      |         ^~~~~~~~~
      |         kfree_skb
drivers/infiniband/sw/rxe/rxe_mr.c: In function 'rxe_dereg_mr':
drivers/infiniband/sw/rxe/rxe_mr.c:734:21: error: macro "kfree_rcu" requires 2 arguments, but only 1 given
  734 |         kfree_rcu(mr);
      |                     ^
In file included from include/linux/rculist.h:11,
                 from include/linux/dcache.h:8,
                 from include/linux/fs.h:8,
                 from include/linux/highmem.h:5,
                 from include/linux/bvec.h:10,
                 from include/linux/blk_types.h:10,
                 from include/linux/bio.h:10,
                 from include/linux/libnvdimm.h:14,
                 from drivers/infiniband/sw/rxe/rxe_mr.c:7:
include/linux/rcupdate.h:984: note: macro "kfree_rcu" defined here
  984 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
      | 
drivers/infiniband/sw/rxe/rxe_mr.c:734:9: error: 'kfree_rcu' undeclared (first use in this function); did you mean 'kfree_skb'?
  734 |         kfree_rcu(mr);
      |         ^~~~~~~~~
      |         kfree_skb
drivers/infiniband/sw/rxe/rxe_mr.c:734:9: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  62a2ac23b35f ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2022-10-18 10:43 ` Frederic Weisbecker
@ 2022-10-18 14:57   ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2022-10-18 14:57 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 18, 2022 at 12:43:56PM +0200, Frederic Weisbecker wrote:
> On Tue, Oct 18, 2022 at 10:26:36AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-intel.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-amd.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcutorture.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcuscale.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/refscale.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [fs/dlm/dlm.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [drivers/pci/controller/vmd.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [drivers/char/ipmi/ipmi_msghandler.ko] undefined!
> > ERROR: modpost: "srcu_check_nmi_safety" [drivers/gpu/drm/drm.ko] undefined!
> > WARNING: modpost: suppressed 10 unresolved symbol warnings because there were too many)
> > 
> > Presumably caused by commit
> > 
> >   54a118fce487 ("srcu: Debug NMI safety even on archs that don't require it")
> 
> My bad. This commit indeed lacks this (Paul can you add the following
> line on that commit?):
> 
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 382236dd5e46..bcd629f5f902 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -651,6 +651,7 @@ void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
>  	}
>  	WARN_ONCE(old_nmi_safe_mask != nmi_safe_mask, "CPU %d old state %d new state %d\n", sdp->cpu, old_nmi_safe_mask, nmi_safe_mask);
>  }
> +EXPORT_SYMBOL_GPL(srcu_check_nmi_safety);
>  #endif /* CONFIG_PROVE_RCU */

On my list for the next rebase, thank you both!  Along with kernel
test robot.  ;-)

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2022-10-17 23:26 Stephen Rothwell
@ 2022-10-18 10:43 ` Frederic Weisbecker
  2022-10-18 14:57   ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Frederic Weisbecker @ 2022-10-18 10:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul E. McKenney, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 18, 2022 at 10:26:36AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-intel.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-amd.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcutorture.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcuscale.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/refscale.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [fs/dlm/dlm.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [drivers/pci/controller/vmd.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [drivers/char/ipmi/ipmi_msghandler.ko] undefined!
> ERROR: modpost: "srcu_check_nmi_safety" [drivers/gpu/drm/drm.ko] undefined!
> WARNING: modpost: suppressed 10 unresolved symbol warnings because there were too many)
> 
> Presumably caused by commit
> 
>   54a118fce487 ("srcu: Debug NMI safety even on archs that don't require it")

My bad. This commit indeed lacks this (Paul can you add the following
line on that commit?):

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 382236dd5e46..bcd629f5f902 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -651,6 +651,7 @@ void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
 	}
 	WARN_ONCE(old_nmi_safe_mask != nmi_safe_mask, "CPU %d old state %d new state %d\n", sdp->cpu, old_nmi_safe_mask, nmi_safe_mask);
 }
+EXPORT_SYMBOL_GPL(srcu_check_nmi_safety);
 #endif /* CONFIG_PROVE_RCU */
 
 /*


Thanks!

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

* linux-next: build failure after merge of the rcu tree
@ 2022-10-17 23:26 Stephen Rothwell
  2022-10-18 10:43 ` Frederic Weisbecker
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2022-10-17 23:26 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Frederic Weisbecker, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-intel.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [arch/x86/kvm/kvm-amd.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcutorture.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/rcuscale.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [kernel/rcu/refscale.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [fs/dlm/dlm.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [drivers/pci/controller/vmd.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [drivers/char/ipmi/ipmi_msghandler.ko] undefined!
ERROR: modpost: "srcu_check_nmi_safety" [drivers/gpu/drm/drm.ko] undefined!
WARNING: modpost: suppressed 10 unresolved symbol warnings because there were too many)

Presumably caused by commit

  54a118fce487 ("srcu: Debug NMI safety even on archs that don't require it")

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2022-04-19  2:36 Stephen Rothwell
@ 2022-04-19  3:31 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2022-04-19  3:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Joel Fernandes, Frederic Weisbecker, Linux Kernel Mailing List,
	Linux Next Mailing List

On Tue, Apr 19, 2022 at 12:36:24PM +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 kernel/rcu/tree.c:5031:
> kernel/rcu/tree_nocb.h: In function 'rcu_init_nohz':
> kernel/rcu/tree_nocb.h:1162:14: error: 'rcu_nocb_is_setup' undeclared (first use in this function); did you mean 'rcu_nocb_setup'?
>  1162 |         if (!rcu_nocb_is_setup) {
>       |              ^~~~~~~~~~~~~~~~~
>       |              rcu_nocb_setup
> kernel/rcu/tree_nocb.h:1162:14: note: each undeclared identifier is reported only once for each function it appears in
> 
> Caused by commit
> 
>   d6932dca19b1 ("rcu/nocb: Add an option to offload all CPUs on boot")
> 
> interacting with commit
> 
>   8d2aaa9b7c29 ("rcu/nocb: Move rcu_nocb_is_setup to rcu_state")
> 
> I have used the rcu tree from next-20220414 for today.

Again, apologies!

I have dropped that commit from -rcu and am retesting, and will update
rcu/next accordingly.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2022-04-19  2:36 Stephen Rothwell
  2022-04-19  3:31 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2022-04-19  2:36 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Joel Fernandes, Frederic Weisbecker, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

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

In file included from kernel/rcu/tree.c:5031:
kernel/rcu/tree_nocb.h: In function 'rcu_init_nohz':
kernel/rcu/tree_nocb.h:1162:14: error: 'rcu_nocb_is_setup' undeclared (first use in this function); did you mean 'rcu_nocb_setup'?
 1162 |         if (!rcu_nocb_is_setup) {
      |              ^~~~~~~~~~~~~~~~~
      |              rcu_nocb_setup
kernel/rcu/tree_nocb.h:1162:14: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  d6932dca19b1 ("rcu/nocb: Add an option to offload all CPUs on boot")

interacting with commit

  8d2aaa9b7c29 ("rcu/nocb: Move rcu_nocb_is_setup to rcu_state")

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2021-05-03  0:11 Stephen Rothwell
@ 2021-05-03 16:25 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2021-05-03 16:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Mon, May 03, 2021 at 10:11:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: modpost: "clocksource_verify_percpu" [kernel/time/clocksource-wdtest.ko] undefined!
> 
> Caused by commit
> 
>   98f0fdb43573 ("clocksource: Provide kernel module to test clocksource watchdog")
> 
> I have used the rcu tree from next-20210430 for today.

Apologies for the hassle and for my losing track of the International
Date Line!  I have updated accordingly.

							Thanx, Paul

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

* linux-next: build failure after merge of the rcu tree
@ 2021-05-03  0:11 Stephen Rothwell
  2021-05-03 16:25 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2021-05-03  0:11 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

ERROR: modpost: "clocksource_verify_percpu" [kernel/time/clocksource-wdtest.ko] undefined!

Caused by commit

  98f0fdb43573 ("clocksource: Provide kernel module to test clocksource watchdog")

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

-- 
Cheers,
Stephen Rothwell

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

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

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

On Thu, Apr 22, 2021 at 02:10:16PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from kernel/rcu/update.c:584:
> kernel/rcu/tasks.h:1404:20: error: static declaration of 'show_rcu_tasks_gp_kthreads' follows non-static declaration
>  1404 | static inline void show_rcu_tasks_gp_kthreads(void) {}
>       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from kernel/rcu/update.c:49:
> kernel/rcu/rcu.h:440:6: note: previous declaration of 'show_rcu_tasks_gp_kthreads' was here
>   440 | void show_rcu_tasks_gp_kthreads(void);
>       |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   4bf02dd6048d ("tasks-rcu: Make show_rcu_tasks_gp_kthreads() be static inline")
> 
> I have used the rcu tree from next-20210421 for today.

Well, that is one commit that isn't going into the upcoming merge window!

I have (allegedly) fixed it with attribution, but also moved it out of
my -next pile.  I will update rcu/next after a quick round of tests.

Apologies for the hassle!

							Thanx, Paul

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

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

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

Hi all,

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

In file included from kernel/rcu/update.c:584:
kernel/rcu/tasks.h:1404:20: error: static declaration of 'show_rcu_tasks_gp_kthreads' follows non-static declaration
 1404 | static inline void show_rcu_tasks_gp_kthreads(void) {}
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from kernel/rcu/update.c:49:
kernel/rcu/rcu.h:440:6: note: previous declaration of 'show_rcu_tasks_gp_kthreads' was here
  440 | void show_rcu_tasks_gp_kthreads(void);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  4bf02dd6048d ("tasks-rcu: Make show_rcu_tasks_gp_kthreads() be static inline")

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2021-03-17  5:36 Stephen Rothwell
@ 2021-03-17 14:23 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2021-03-17 14:23 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: build failure after merge of the rcu tree
@ 2021-03-17  5:36 Stephen Rothwell
  2021-03-17 14:23 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2021-03-17  5:36 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2021-01-04  0:37 Stephen Rothwell
@ 2021-01-04 12:56 ` Frederic Weisbecker
  0 siblings, 0 replies; 152+ messages in thread
From: Frederic Weisbecker @ 2021-01-04 12:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paul E. McKenney, Linux Kernel Mailing List, Linux Next Mailing List

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



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

* linux-next: build failure after merge of the rcu tree
@ 2021-01-04  0:37 Stephen Rothwell
  2021-01-04 12:56 ` Frederic Weisbecker
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2021-01-04  0:37 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Frederic Weisbecker, Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-12-07  4:48     ` Paul E. McKenney
@ 2020-12-07  8:59       ` Stephen Rothwell
  0 siblings, 0 replies; 152+ messages in thread
From: Stephen Rothwell @ 2020-12-07  8:59 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Paul,

On Sun, 6 Dec 2020 20:48:41 -0800 "Paul E. McKenney" <paulmck@kernel.org> 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" <paulmck@kernel.org> 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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-12-06 21:39   ` Stephen Rothwell
@ 2020-12-07  4:48     ` Paul E. McKenney
  2020-12-07  8:59       ` Stephen Rothwell
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2020-12-07  4:48 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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" <paulmck@kernel.org> 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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-12-04 19:20 ` Paul E. McKenney
@ 2020-12-06 21:39   ` Stephen Rothwell
  2020-12-07  4:48     ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-12-06 21:39 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Paul,

On Fri, 4 Dec 2020 11:20:32 -0800 "Paul E. McKenney" <paulmck@kernel.org> 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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-12-04  8:25 Stephen Rothwell
@ 2020-12-04 19:20 ` Paul E. McKenney
  2020-12-06 21:39   ` Stephen Rothwell
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2020-12-04 19:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>

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.

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

* linux-next: build failure after merge of the rcu tree
@ 2020-12-04  8:25 Stephen Rothwell
  2020-12-04 19:20 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-12-04  8:25 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-09-17 22:01 ` Paul E. McKenney
@ 2020-09-18  0:00   ` Stephen Rothwell
  0 siblings, 0 replies; 152+ messages in thread
From: Stephen Rothwell @ 2020-09-18  0:00 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Paul,

On Thu, 17 Sep 2020 15:01:45 -0700 "Paul E. McKenney" <paulmck@kernel.org> 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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-09-17  5:19 Stephen Rothwell
@ 2020-09-17 22:01 ` Paul E. McKenney
  2020-09-18  0:00   ` Stephen Rothwell
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2020-09-17 22:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: build failure after merge of the rcu tree
@ 2020-09-17  5:19 Stephen Rothwell
  2020-09-17 22:01 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-09-17  5:19 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

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

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

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

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

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

* linux-next: build failure after merge of the rcu tree
@ 2020-09-08  5:38 Stephen Rothwell
  2020-09-08 13:54 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-09-08  5:38 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-08-18  1:43 Stephen Rothwell
@ 2020-08-18 14:08 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2020-08-18 14:08 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: build failure after merge of the rcu tree
@ 2020-08-18  1:43 Stephen Rothwell
  2020-08-18 14:08 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-08-18  1:43 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-06-25  2:57 Stephen Rothwell
@ 2020-06-25  3:45 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2020-06-25  3:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

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, &rdp->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, &rdp->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(&rdp->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

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

* linux-next: build failure after merge of the rcu tree
@ 2020-06-25  2:57 Stephen Rothwell
  2020-06-25  3:45 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-06-25  2:57 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peter Zijlstra

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

Hi all,

After merging the rcu tree, today's linux-next build (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, &rdp->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, &rdp->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(&rdp->dynticks) & RCU_DYNTICK_CTRL_CTR);
      |           ^~~~~~~~~~~~~~~~
      |           atomic_read

Caused by commit

  d2f8491368e5 ("rcu: Fixup noinstr warnings")

I reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-05-28 16:33 ` Paul E. McKenney
@ 2020-05-28 21:03   ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2020-05-28 21:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-05-28  9:05 Stephen Rothwell
@ 2020-05-28 16:33 ` Paul E. McKenney
  2020-05-28 21:03   ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2020-05-28 16:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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 <sfr@canb.auug.org.au>
> Date: Thu, 28 May 2020 18:57:17 +1000
> Subject: [PATCH] refperf: uniqify name
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  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 = &srcu_ctl_perf;
> +DEFINE_STATIC_SRCU(ref_srcu_ctl_perf);
> +static struct srcu_struct *srcu_ctlp = &ref_srcu_ctl_perf;
>  
>  static void srcu_ref_perf_read_section(int nloops)
>  {
> -- 
> 2.26.2
> 
> -- 
> Cheers,
> Stephen Rothwell



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

* linux-next: build failure after merge of the rcu tree
@ 2020-05-28  9:05 Stephen Rothwell
  2020-05-28 16:33 ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2020-05-28  9:05 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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

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 <sfr@canb.auug.org.au>
Date: Thu, 28 May 2020 18:57:17 +1000
Subject: [PATCH] refperf: uniqify name

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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 = &srcu_ctl_perf;
+DEFINE_STATIC_SRCU(ref_srcu_ctl_perf);
+static struct srcu_struct *srcu_ctlp = &ref_srcu_ctl_perf;
 
 static void srcu_ref_perf_read_section(int nloops)
 {
-- 
2.26.2

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2020-04-05  1:49 Stephen Rothwell
@ 2020-04-05  3:10 ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2020-04-05  3:10 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

On Sun, Apr 05, 2020 at 11:49:59AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/trace/ftrace.c: In function 'ftrace_shutdown':
> kernel/trace/ftrace.c:2924:3: error: implicit declaration of function 'synchronize_rcu_tasks_rude'; did you mean 'synchronize_rcu_tasks'? [-Werror=implicit-function-declaration]
>  2924 |   synchronize_rcu_tasks_rude();
>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~
>       |   synchronize_rcu_tasks
> 
> Caused by commit
> 
>   59377f3e06b8 ("ftrace: Use synchronize_rcu_tasks_rude() instead of ftrace_sync()")
> 
> synchronize_rcu_tasks_rude() is only declared when
> CONFIG_TASKS_RCU_GENERIC is defined.
> 
> I have reverted that commit for today.
> 
> Just asking: are all the commits currently in the rcu tree actually
> intended for v5.7?

My bad!  I have moved rcu/next to where it need to be for the duration
of the merge window.  Please accept my apologies for the hassle.

							Thanx, Paul

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

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

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

Hi all,

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

kernel/trace/ftrace.c: In function 'ftrace_shutdown':
kernel/trace/ftrace.c:2924:3: error: implicit declaration of function 'synchronize_rcu_tasks_rude'; did you mean 'synchronize_rcu_tasks'? [-Werror=implicit-function-declaration]
 2924 |   synchronize_rcu_tasks_rude();
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |   synchronize_rcu_tasks

Caused by commit

  59377f3e06b8 ("ftrace: Use synchronize_rcu_tasks_rude() instead of ftrace_sync()")

synchronize_rcu_tasks_rude() is only declared when
CONFIG_TASKS_RCU_GENERIC is defined.

I have reverted that commit for today.

Just asking: are all the commits currently in the rcu tree actually
intended for v5.7?
-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-12-12  2:45 Stephen Rothwell
  2019-12-12  4:07 ` Paul E. McKenney
@ 2020-01-17  3:09 ` Stephen Rothwell
  1 sibling, 0 replies; 152+ messages in thread
From: Stephen Rothwell @ 2020-01-17  3:09 UTC (permalink / raw)
  To: Paul E. McKenney, David Howells
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

On Thu, 12 Dec 2019 13:45:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/misc/watch_queue.c: In function 'watch_queue_set_filter':
> drivers/misc/watch_queue.c:526:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
>   526 |  rcu_swap_protected(wqueue->filter, wfilter,
>       |  ^~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   af8c9224182e ("rcu: Remove rcu_swap_protected()")
> 
> interacting with commit
> 
>   fe78d401ca6b ("General notification queue with user mmap()'able ring buffer")
> 
> from the keys tree.
> 
> I have added the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Dec 2019 13:37:52 +1100
> Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/misc/watch_queue.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/misc/watch_queue.c b/drivers/misc/watch_queue.c
> index b3fc59b4ef6c..a4a77ec977ac 100644
> --- a/drivers/misc/watch_queue.c
> +++ b/drivers/misc/watch_queue.c
> @@ -523,8 +523,8 @@ static long watch_queue_set_filter(struct inode *inode,
>  	kfree(tf);
>  set:
>  	inode_lock(inode);
> -	rcu_swap_protected(wqueue->filter, wfilter,
> -			   lockdep_is_held(&inode->i_rwsem));
> +	wfilter = rcu_replace_pointer(wqueue->filter, wfilter,
> +				      lockdep_is_held(&inode->i_rwsem));
>  	inode_unlock(inode);
>  	if (wfilter)
>  		kfree_rcu(wfilter, rcu);

This has bee replaced with this patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Dec 2019 13:37:52 +1100
Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"

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

diff --git a/kernel/watch_queue.c b/kernel/watch_queue.c
index d48f422f391a..f195cbbbb3d3 100644
--- a/kernel/watch_queue.c
+++ b/kernel/watch_queue.c
@@ -354,8 +354,8 @@ long watch_queue_set_filter(struct pipe_inode_info *pipe,
 	kfree(tf);
 set:
 	pipe_lock(pipe);
-	rcu_swap_protected(wqueue->filter, wfilter,
-			   lockdep_is_held(&pipe->mutex));
+	wfilter = rcu_replace_pointer(wqueue->filter, wfilter,
+				      lockdep_is_held(&pipe->mutex));
 	pipe_unlock(pipe);
 	if (wfilter)
 		kfree_rcu(wfilter, rcu);

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the rcu tree
@ 2020-01-17  3:07 Stephen Rothwell
  0 siblings, 0 replies; 152+ messages in thread
From: Stephen Rothwell @ 2020-01-17  3:07 UTC (permalink / raw)
  To: Paul E. McKenney, David Howells
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

security/keys/permission.c: In function 'key_set_acl':
security/keys/permission.c:273:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
  273 |  rcu_swap_protected(key->acl, acl, lockdep_is_held(&key->sem));
      |  ^~~~~~~~~~~~~~~~~~
security/keys/permission.c:273:36: error: implicit declaration of function 'lockdep_is_held'; did you mean 'lockdep_is_held_type'? [-Werror=implicit-function-declaration]
  273 |  rcu_swap_protected(key->acl, acl, lockdep_is_held(&key->sem));
      |                                    ^~~~~~~~~~~~~~~
      |                                    lockdep_is_held_type

Caused by commit

  4414abf89158 ("rcu: Remove rcu_swap_protected()")

interacting with commit

  af94dc1ff4c9 ("keys: Replace uid/gid/perm permissions checking with an ACL")

from the keys tree.

I have added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Jan 2020 14:04:13 +1100
Subject: [PATCH] fixup 2 for removal of rcu_swap_protected

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

diff --git a/security/keys/permission.c b/security/keys/permission.c
index a651b3fd2007..f42e67b51aea 100644
--- a/security/keys/permission.c
+++ b/security/keys/permission.c
@@ -270,7 +270,7 @@ long key_set_acl(struct key *key, struct key_acl *acl)
 		}
 	}
 
-	rcu_swap_protected(key->acl, acl, lockdep_is_held(&key->sem));
+	acl = rcu_replace_pointer(key->acl, acl, lockdep_is_held(&key->sem));
 	key_put_acl(acl);
 	notify_key(key, NOTIFY_KEY_SETATTR, 0);
 	return 0;
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-12-12  4:26   ` Stephen Rothwell
@ 2019-12-12  4:41     ` Paul E. McKenney
  0 siblings, 0 replies; 152+ messages in thread
From: Paul E. McKenney @ 2019-12-12  4:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Howells, Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Dec 12, 2019 at 03:26:13PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Wed, 11 Dec 2019 20:07:37 -0800 "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >
> > On Thu, Dec 12, 2019 at 01:45:16PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/misc/watch_queue.c: In function 'watch_queue_set_filter':
> > > drivers/misc/watch_queue.c:526:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
> > >   526 |  rcu_swap_protected(wqueue->filter, wfilter,
> > >       |  ^~~~~~~~~~~~~~~~~~
> > > 
> > > Caused by commit
> > > 
> > >   af8c9224182e ("rcu: Remove rcu_swap_protected()")
> > > 
> > > interacting with commit
> > > 
> > >   fe78d401ca6b ("General notification queue with user mmap()'able ring buffer")
> > > 
> > > from the keys tree.
> > > 
> > > I have added the following merge fix patch for today:
> > > 
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 12 Dec 2019 13:37:52 +1100
> > > Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>  
> > 
> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Thanks.
> 
> > I would be happy to take this if desired, but it would probably be better
> > for this to be applied directly to the keys tree.  Either way, please let
> > me know.
> 
> Well, you can't take this fix up without merging the keys tree ... and
> the keys tree is currently in flux so it should be easy for it to be
> applied there since rcu_replace_pointer() already exists in Linus'
> tree, right?.

Yes, so sounds like a plan to me.  ;-)

							Thanx, Paul

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-12-12  4:07 ` Paul E. McKenney
@ 2019-12-12  4:26   ` Stephen Rothwell
  2019-12-12  4:41     ` Paul E. McKenney
  0 siblings, 1 reply; 152+ messages in thread
From: Stephen Rothwell @ 2019-12-12  4:26 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: David Howells, Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Paul,

On Wed, 11 Dec 2019 20:07:37 -0800 "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> On Thu, Dec 12, 2019 at 01:45:16PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/misc/watch_queue.c: In function 'watch_queue_set_filter':
> > drivers/misc/watch_queue.c:526:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
> >   526 |  rcu_swap_protected(wqueue->filter, wfilter,
> >       |  ^~~~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   af8c9224182e ("rcu: Remove rcu_swap_protected()")
> > 
> > interacting with commit
> > 
> >   fe78d401ca6b ("General notification queue with user mmap()'able ring buffer")
> > 
> > from the keys tree.
> > 
> > I have added the following merge fix patch for today:
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 12 Dec 2019 13:37:52 +1100
> > Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>  
> 
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

Thanks.

> I would be happy to take this if desired, but it would probably be better
> for this to be applied directly to the keys tree.  Either way, please let
> me know.

Well, you can't take this fix up without merging the keys tree ... and
the keys tree is currently in flux so it should be easy for it to be
applied there since rcu_replace_pointer() already exists in Linus'
tree, right?.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the rcu tree
  2019-12-12  2:45 Stephen Rothwell
@ 2019-12-12  4:07 ` Paul E. McKenney
  2019-12-12  4:26   ` Stephen Rothwell
  2020-01-17  3:09 ` Stephen Rothwell
  1 sibling, 1 reply; 152+ messages in thread
From: Paul E. McKenney @ 2019-12-12  4:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Howells, Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Dec 12, 2019 at 01:45:16PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/misc/watch_queue.c: In function 'watch_queue_set_filter':
> drivers/misc/watch_queue.c:526:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
>   526 |  rcu_swap_protected(wqueue->filter, wfilter,
>       |  ^~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   af8c9224182e ("rcu: Remove rcu_swap_protected()")
> 
> interacting with commit
> 
>   fe78d401ca6b ("General notification queue with user mmap()'able ring buffer")
> 
> from the keys tree.
> 
> I have added the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Dec 2019 13:37:52 +1100
> Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

I would be happy to take this if desired, but it would probably be better
for this to be applied directly to the keys tree.  Either way, please let
me know.

							Thanx, Paul

> ---
>  drivers/misc/watch_queue.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/misc/watch_queue.c b/drivers/misc/watch_queue.c
> index b3fc59b4ef6c..a4a77ec977ac 100644
> --- a/drivers/misc/watch_queue.c
> +++ b/drivers/misc/watch_queue.c
> @@ -523,8 +523,8 @@ static long watch_queue_set_filter(struct inode *inode,
>  	kfree(tf);
>  set:
>  	inode_lock(inode);
> -	rcu_swap_protected(wqueue->filter, wfilter,
> -			   lockdep_is_held(&inode->i_rwsem));
> +	wfilter = rcu_replace_pointer(wqueue->filter, wfilter,
> +				      lockdep_is_held(&inode->i_rwsem));
>  	inode_unlock(inode);
>  	if (wfilter)
>  		kfree_rcu(wfilter, rcu);
> -- 
> 2.24.0
> 
> -- 
> Cheers,
> Stephen Rothwell



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

* linux-next: build failure after merge of the rcu tree
@ 2019-12-12  2:45 Stephen Rothwell
  2019-12-12  4:07 ` Paul E. McKenney
  2020-01-17  3:09 ` Stephen Rothwell
  0 siblings, 2 replies; 152+ messages in thread
From: Stephen Rothwell @ 2019-12-12  2:45 UTC (permalink / raw)
  To: Paul E. McKenney, David Howells
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

drivers/misc/watch_queue.c: In function 'watch_queue_set_filter':
drivers/misc/watch_queue.c:526:2: error: implicit declaration of function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
  526 |  rcu_swap_protected(wqueue->filter, wfilter,
      |  ^~~~~~~~~~~~~~~~~~

Caused by commit

  af8c9224182e ("rcu: Remove rcu_swap_protected()")

interacting with commit

  fe78d401ca6b ("General notification queue with user mmap()'able ring buffer")

from the keys tree.

I have added the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Dec 2019 13:37:52 +1100
Subject: [PATCH] rcu: fix up for "Remove rcu_swap_protected()"

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

diff --git a/drivers/misc/watch_queue.c b/drivers/misc/watch_queue.c
index b3fc59b4ef6c..a4a77ec977ac 100644
--- a/drivers/misc/watch_queue.c
+++ b/drivers/misc/watch_queue.c
@@ -523,8 +523,8 @@ static long watch_queue_set_filter(struct inode *inode,
 	kfree(tf);
 set:
 	inode_lock(inode);
-	rcu_swap_protected(wqueue->filter, wfilter,
-			   lockdep_is_held(&inode->i_rwsem));
+	wfilter = rcu_replace_pointer(wqueue->filter, wfilter,
+				      lockdep_is_held(&inode->i_rwsem));
 	inode_unlock(inode);
 	if (wfilter)
 		kfree_rcu(wfilter, rcu);
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

Or do you have a better approach?

							Thanx, Paul

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



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

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

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

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

							Thanx, Paul

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



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

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

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

Hi all,

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

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

Caused by commit

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

lock_is_held() us only available if CONFIG_LOCKDEP is set.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi Paul,

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

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

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

							Thanx, Paul

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



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

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

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

Hi all,

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

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

Caused by commit

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

Also:

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

Caused by commits:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Sorry for the hassle!

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

							Thanx, Paul

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

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

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

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

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

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

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

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

Basically:

	CPU0				CPU1

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

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

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

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

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

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

down_read()
	p->state = TASK_UNINTERRUPTIBLE;

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


p->state = TASK_DEAD

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

__schedule(false);
BUG();




So given that, I think that:

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

  current->state = TASK_DEAD;

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

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

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

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

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

My reasoning is as follows:

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

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

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

							Thanx, Paul

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

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

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

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

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

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

On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/sched/core.c: In function 'do_task_dead':
> kernel/sched/core.c:3385:2: error: implicit declaration of function 'smp_mb__before_spinlock' [-Werror=implicit-function-declaration]
>   smp_mb__before_spinlock();
>   ^
> cc1: some warnings being treated as errors
> 
> Caused by commit
> 
>   4a6fc6107e90 ("sched: Replace spin_unlock_wait() with lock/unlock pair")
> 
> Interacting with commit
> 
>   a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")
> 
> from the tip tree.
> 
> I applied this patch for now, but I assume something better is required.

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

Peter, any objections to that approach?  Other suggestions?

							Thanx, Paul

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

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

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

Hi Paul,

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

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

Caused by commit

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

Interacting with commit

  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

from the tip tree.

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

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

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

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

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

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

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

Does the following patch fix things for you?

							Thanx, Paul

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

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

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

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

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

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

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

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

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

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

Where pr_alert() is:

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


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

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

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

cheers

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

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

Hi Joe,

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

							Thanx, Paul

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

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

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

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

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

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

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

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

Hi Paul,

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

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

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

This reverts commit b75a9e6bfba5c7343391ac1bacd44d6652dde8da.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

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

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

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

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

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

Anyone see any other options?

								Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

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

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

added by commit

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

before v2.6.39-rc2 ...

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

[Also reported by Michael elsewhere]

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

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

Caused by commit

  b2bb79507ba1 ("srcu: Parallelize callback handling")

I have left it broken for today.

-- 
Cheers,
Stephen Rothwell

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

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

Hi Paul,

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

What I live for :-)

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

							Thanx, Paul

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

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

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

Glad you like it!  ;-)

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

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

							Thanx, Paul

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

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

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

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

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

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

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

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

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

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

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

On my list for tomorrow morning.  ;-)

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

interacting with commit

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

from the drm-intel tree.

I added the following merge fix patch:

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi Paul,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi Paul,

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

OK, thanks.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

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

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

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

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

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

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

                                                      Thanx, Paul

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

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

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

Hi Paul,

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

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

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

							Thanx, Paul

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

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

Hi Paul,

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

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

Caused by commit

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Applied, thank you!

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

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

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

I hope so.  ;-)

							Thanx, Paul

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

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

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

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

Looks very good to me ;-)

Regards,
Boqun

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

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

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

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

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

FWIW,

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

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

Thanks.

-- 
tejun

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

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

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

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

							Thanx, Paul

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

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

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

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

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

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

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

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

Interesting ;-) Thank you.

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

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

Regards,
Boqun

> 							Thanx, Paul
> 

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

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

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

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

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

							Thanx, Paul

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

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

Hi Boqun,

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

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

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

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

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

Hi Paul,

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

from include/linux/percpu-defs.h:

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

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

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

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

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

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

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

							Thanx, Paul

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

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

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

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

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

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

The definition of __DEFINE_STATIC_SRCU is:

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

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

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

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

Mind to check your config options, Stephen?


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

Cc Tejun and Christoph for their opinions.

Regards,
Boqun

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

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

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

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

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

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

Here is a patch that I will be merging in.

							Thanx, Paul

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

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

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

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

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

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

Hi Paul,

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

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

OK, I looked further and

DEFINE_STATIC_SRCU(srcu_ctl);

becomes this (NLs added for clarity):

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

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

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

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

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

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

Hello, Stephen,

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

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

						Thanx, Paul

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

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

Hi Paul,

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

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

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

Caused by commit

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

I have reverted that commit for today.

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

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

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

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

Very good, queued for 4.4!

							Thanx, Paul

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

sched: Export sched_setscheduler_nocheck

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

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

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

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

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


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

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


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

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

The export looks good to me:

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

Thanks,

	Ingo

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

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

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

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

							Thanx, Paul

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


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

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

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

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

Thanks,
Davidlohr

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

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

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

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

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




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

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

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

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

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

Thoughts?

							Thanx, Paul


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

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

Hi Paul,

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

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

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

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

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

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

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

							Thanx, Paul


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

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

Hi Paul,

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

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

Caused by commits

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

and maybe more.

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

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

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

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


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

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

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

Thanks,

	Ingo

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

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

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

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

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

Thank you!

							Thanx, Paul


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

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


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

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

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

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

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

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

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

Thanks,

	Ingo

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

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

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

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

Thoughts?

							Thanx, Paul

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

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


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

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

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

Works for me!  Will do.

							Thanx, Paul


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

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


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

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

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

Thanks,

	Ingo

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

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

Hi Paul,

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

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

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

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

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

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

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

							Thanx, Paul

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


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

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

Hi Paul,

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

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

Caused by commit

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

interacting with commit

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

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

from the tip tree.

I added the following merge fix patch:

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

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

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

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

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

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

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

Apologies for the hassle!  I have fixed this.

							Thanx, Paul


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

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

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

Hi Paul,

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

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

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

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

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

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

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

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

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

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

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

Make sense?

							Thanx, Paul


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

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

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

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

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

-- 
Pranith

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

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

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

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

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

-- 
Pranith

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

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

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

Hello, Stephen,

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

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

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

							Thanx, Paul


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

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

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

Hi Paul,

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

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

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

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

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

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

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

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

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

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

							Thanx, Paul


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

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

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

Hi Paul,

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

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

I am sure we have seen this before :-(

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

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

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

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

Done!

							Thanx, Paul


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

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

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

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

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

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

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

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

Hi Paul,

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

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

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

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

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

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

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

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

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

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

							Thanx, Paul


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

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

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

Hi Paul,

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

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

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

Presumably caused by commit 44dec3761b63 ("srcu: Isolate srcu sections
using CONFIG_SRCU") and reverting that commit makes the messages go
away, so I have done that for today.

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

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

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

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

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

<red face>

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

							Thanx, Paul


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

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

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

Hi Paul,

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

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

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

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

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

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

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

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

Good catch, thank you!!!

							Thanx, Paul

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

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

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

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

Thanks guys




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

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

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

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

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

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

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

Hi Paul,

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

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

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

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

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

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

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

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

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

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

end of thread, other threads:[~2024-01-24 14:20 UTC | newest]

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).