linux-kernel - Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151008174650.GD3910@linux.vnet.ibm.com>
Date:	Thu, 8 Oct 2015 10:46:50 -0700
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 02/18] rcu: Move rcu_report_exp_rnp() to
 allow consolidation

On Thu, Oct 08, 2015 at 07:12:03PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote:
> 
> > > > o	CPU B therefore moves up the tree, acquiring the parent
> > > > 	rcu_node structures' ->lock.  In so doing, it forces full
> > > > 	ordering against all prior RCU read-side critical sections
> > > > 	of all CPUs corresponding to all leaf rcu_node structures
> > > > 	subordinate to the current (non-leaf) rcu_node structure.
> > > 
> > > And here we iterate the tree and get another lock var involved, here the
> > > barrier upgrade will actually do something.
> > 
> > Yep.  And I am way too lazy to sort out exactly which acquisitions really
> > truly need smp_mb__after_unlock_lock() and which don't.  Besides, if I
> > tried to sort it out, I would occasionally get it wrong, and this would be
> > a real pain to debug.  Therefore, I simply do smp_mb__after_unlock_lock()
> > on all acquisitions of the rcu_node structures' ->lock fields.  I can
> > actually validate that!  ;-)
> 
> This is a whole different line of reasoning once again.
> 
> The point remains, that the sole purpose of the barrier upgrade is for
> the tree iteration, having some extra (pointless but harmless) instances
> does not detract from that.
> 
> > Fair enough, but I will be sticking to the simple coding rule that keeps
> > RCU out of trouble!
> 
> Note that there are rnp->lock acquires without the extra barrier though,
> so you seem somewhat inconsistent with your own rule.
> 
> See for example:
> 
> 	rcu_dump_cpu_stacks()
> 	print_other_cpu_stall()
> 	print_cpu_stall()
> 
> (did not do an exhaustive scan, there might be more)
> 
> and yes, that is 'obvious' debug code and not critical to the correct
> behaviour of the code, but it is a deviation from 'the rule'.

Which I need to fix, thank you.

							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/