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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 16 Jan 2017 13:01:11 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, mingo@...nel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
        fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended
 quiescent state enter/exit operations

On Mon, Jan 16, 2017 at 05:43:37PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 14, 2017 at 12:54:42AM -0800, Paul E. McKenney wrote:
> >  /*
> > + * Record entry into an extended quiescent state.  This is only to be
> > + * called when not already in an extended quiescent state.
> > + */
> > +static void rcu_dynticks_eqs_enter(void)
> > +{
> > +	struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
> > +
> > +	/*
> > +	 * CPUs seeing atomic_inc() must see prior RCU read-side critical
> > +	 * sections, and we also must force ordering with the next idle
> > +	 * sojourn.
> > +	 */
> > +	smp_mb__before_atomic(); /* See above. */
> > +	atomic_inc(&rdtp->dynticks);
> > +	smp_mb__after_atomic(); /* See above. */
> > +	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > +		     atomic_read(&rdtp->dynticks) & 0x1);
> > +}
> 
> In an earlier patch you replaced things with atomic_add_return(), why
> not use atomic_inc_return() here?

The rationale is that the earlier patch uses the return value
unconditionally, while at this site, the return value would be used only
if CONFIG_RCU_EQS_DEBUG.  But mostly inertia.

							Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ