linux-kernel - Re: [PATCH tip/core/rcu 01/45] rcutorture: Add forward-progress checking for writer

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]

Date:	Fri, 9 May 2014 10:36:58 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	niv@...ibm.com, tglx@...utronix.de, peterz@...radead.org,
	rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
	darren@...art.com, fweisbec@...il.com, oleg@...hat.com, sbw@....edu
Subject: Re: [PATCH tip/core/rcu 01/45] rcutorture: Add forward-progress
 checking for writer

On Fri, May 09, 2014 at 08:52:31AM -0700, Josh Triplett wrote:
> On Wed, May 07, 2014 at 04:43:13PM -0700, Paul E. McKenney wrote:
> > On Wed, May 07, 2014 at 02:16:49PM -0700, josh@...htriplett.org wrote:
> > > On Mon, Apr 28, 2014 at 05:24:49PM -0700, Paul E. McKenney wrote:
> > > > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > > > 
> > > > The rcutorture output currently does not distinguish between stalls in
> > > > the RCU implementation and stalls in the rcu_torture_writer() kthreads.
> > > > This commit therefore adds some diagnostics to help distinguish between
> > > > these two conditions, at least for the non-SRCU implementations.  (SRCU
> > > > does not provide evidence of update-side forward progress by design.)
> > > > 
> > > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > > 
> > > The concept makes sense, and the writer state annotations seem like a
> > > useful debugging mechanism, but having RCU know about RCU torture types
> > > seems fundamentally wrong.  This mechanism accesses rcu_state, which is
> > > already implementation-specific, so why not just only define the
> > > function for the RCU implementations that support it, and then have a
> > > function pointer in the torture-test structure to report a stall?
> > 
> > Ouch.  It is worse than that!  When running RCU-bh or RCU-sched,
> > the current code incorrectly returns the statistics for RCU.
> > So I do need some way for rcutorture to tell RCU which flavor
> > it is testing.
> > 
> > One thing I could do would be to pass in a pointer to the call_rcu()
> > function (cur_ops->call from rcutorture's viewpoint), then scan the
> > rcu_state structures looking for the selected flavor (rsp->call from
> > tree.c's viewpoint).  In the SRCU and RCU-busted cases, the flavor would
> > not be found, and I could then just set everything to zero.
> > 
> > Does that seem reasonable, or is there a better way to do this?
> 
> That search seems rather too hackish; why not just declare one
> stats-returning function per RCU flavor, and put the pointer to the
> corresponding function in the structure for each test type?

The problem is that rcutorture doesn't know anything about the structures,
as those are internal to the implementation.  All it knows is which
functions it is using.  I -could- EXPORT_SYMBOL_GPL() the rcu_state
structures to modules (they are already non-static), then rename
TINY_RCU's rcu_ctrlblk to rcu_state to allow the needed type punning,
then do some special-case thing for SRCU, and put a pointer to whatever
in rcu_torture_ops, but that was feeling a bit hackish as well.

So what did you have in mind to allow rcutorture to communicate the
rcuflavor to the underlying RCU implementation?

							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/