All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.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: Thu, 7 Jan 2016 19:41:57 -0800	[thread overview]
Message-ID: <20160108034157.GZ3818@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160108013631.GA11410@fixme-laptop.cn.ibm.com>

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

  reply	other threads:[~2016-01-08  3:41 UTC|newest]

Thread overview: 156+ 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
2016-01-08  3:41         ` Paul E. McKenney [this message]
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  1:16 ` Stephen Rothwell
2017-03-08 10:13 ` Daniel Vetter
2017-03-08 10:13   ` Daniel Vetter
2017-03-08 17:40   ` Paul E. McKenney
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  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=20160108034157.GZ3818@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=boqun.feng@gmail.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.