linux-kernel - Re: [GIT PULL] RCU changes for v4.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150415041243.GQ23685@linux.vnet.ibm.com>
Date:	Tue, 14 Apr 2015 21:12:43 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] RCU changes for v4.1

On Tue, Apr 14, 2015 at 08:19:57PM -0700, Linus Torvalds wrote:
> On Tue, Apr 14, 2015 at 7:55 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> >
> > Does the (currently being tested) patch below fix things up?  If not,
> > please fill me in on the further error of my ways.
> 
> Looks ok.
> 
> That said, couldn't that last dummy gp_init_delay variable:
> 
> > +/* Delay in jiffies for grace-period initialization delays, debug only. */
> > +#ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT
> > +static int gp_init_delay = CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY;
> >  module_param(gp_init_delay, int, 0644);
> > +#else /* #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */
> > +static const int gp_init_delay;
> > +#endif /* #else #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */
> 
> be just a
> 
>   #define gp_init_delay 0
> 
> for the non-CONFIG_RCU_TORTURE_TEST_SLOW_INIT case, so that the code
> that then does
> 
> +               if (gp_init_delay > 0 &&
> +                   !(rsp->gpnum % (rcu_num_nodes * PER_RCU_NODE_PERIOD)))
> 
> would just trivially compile away.
> 
> I guess the compiler *might* see a 'static const int' that is never
> touched and realize it's always zero, but it's not obvious that will
> be the case.

Well, if I attempt to modify gp_init_delay in its const guise, for
example, using gp_init_delay++, I get the following:

	/media/homes/git/linux-2.6-tip/kernel/rcu/tree.c: In function ‘rcu_gp_init’:
	/media/homes/git/linux-2.6-tip/kernel/rcu/tree.c:1849:3: error: increment of read-only variable ‘gp_init_delay’
	make[2]: *** [kernel/rcu/tree.o] Error 1
	make[1]: *** [kernel/rcu/tree.o] Error 2
	make[1]: Leaving directory `/tmp/b'
	make: *** [sub-make] Error 2

So the compiler knows that it cannot change.  And if I compile with
CONFIG_RCU_TORTURE_TEST_SLOW_INIT=y, then:

	$ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay
	00000060 r __param_gp_init_delay
	000000e3 r __param_str_gp_init_delay
	00000444 d gp_init_delay

On the other hand, compiling with CONFIG_RCU_TORTURE_TEST_SLOW_INIT=n
results in:

	$ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay

So the compiler isn't creating a variable in the const case.

>From what I can see, at -O1 or better, gcc optimizes the const variable
away.  At -O0, gcc allocates space for it and actually tests it.

But if you prefer #define, not a problem.

							Thanx, Paul

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