linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@linux-foundation.org>
Subject: Re: linux-next: build failure after merge of the rcu tree
Date: Fri, 8 Jan 2016 09:37:04 +0800	[thread overview]
Message-ID: <20160108013631.GA11410@fixme-laptop.cn.ibm.com> (raw)
In-Reply-To: <20160107205220.GU3818@linux.vnet.ibm.com>

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

  reply	other threads:[~2016-01-08  1:37 UTC|newest]

Thread overview: 152+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07  8:57 linux-next: build failure after merge of the rcu tree 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 [this message]
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
  -- 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
2015-09-01  3:50 Stephen Rothwell
2015-09-01  7:49 ` Paul E. McKenney
2015-09-02  3:58   ` Stephen Rothwell
2015-09-02  5:26     ` Paul E. McKenney
2015-09-02  6:40       ` Davidlohr Bueso
2015-09-02  7:14         ` Paul E. McKenney
2015-09-02  7:29           ` Ingo Molnar
2015-09-02  8:34             ` Paul E. McKenney
2015-07-16  3:14 Stephen Rothwell
2015-07-16  3:51 ` Paul E. McKenney
2015-07-16  5:50   ` Stephen Rothwell
2015-07-17 11:40   ` Ingo Molnar
2015-07-17 17:35     ` Paul E. McKenney
2015-07-17 18:53       ` Paul E. McKenney
2015-07-17 19:51         ` Ingo Molnar
2015-07-17 21:33           ` Paul E. McKenney
2015-07-18  2:40             ` Ingo Molnar
2015-04-13 10:39 Stephen Rothwell
2015-04-13 11:06 ` Borislav Petkov
2015-04-13 11:34   ` Ingo Molnar
2015-04-13 12:40     ` Paul E. McKenney
2015-02-27  2:18 Stephen Rothwell
2015-02-27  5:59 ` Paul E. McKenney
2014-12-26  7:51 Stephen Rothwell
2014-12-26 16:54 ` Paul E. McKenney
2014-12-27 16:24   ` Pranith Kumar
2014-12-27 17:20     ` Pranith Kumar
2014-12-31  1:45       ` Paul E. McKenney
2014-12-12  6:12 Stephen Rothwell
2014-12-12 17:23 ` Paul E. McKenney
2014-12-10  8:09 Stephen Rothwell
2014-12-10 15:03 ` Pranith Kumar
2014-12-10 15:18   ` Paul E. McKenney
2014-12-09 11:42 Stephen Rothwell
2014-12-09 14:07 ` Paul E. McKenney
2012-04-16  4:11 Stephen Rothwell
2012-04-16 17:02 ` Paul E. McKenney
2010-09-17  2:42 Stephen Rothwell
2010-09-17  4:39 ` David Miller
2010-09-17  5:34   ` Eric Dumazet
2010-09-17 23:17 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160108013631.GA11410@fixme-laptop.cn.ibm.com \
    --to=boqun.feng@gmail.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).