linux-kernel - Re: [PATCH tip/core/rcu 16/86] rcu: make rcutorture version numbers available through debugfs

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: <20110502083024.GX2297@linux.vnet.ibm.com>
Date:	Mon, 2 May 2011 01:30:24 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	patches@...aro.org, "Paul E. McKenney" <paul.mckenney@...aro.org>
Subject: Re: [PATCH tip/core/rcu 16/86] rcu: make rcutorture version
 numbers available through debugfs

On Sun, May 01, 2011 at 08:29:03AM -0700, Josh Triplett wrote:
> On Sun, May 01, 2011 at 06:20:56AM -0700, Paul E. McKenney wrote:
> > From: Paul E. McKenney <paul.mckenney@...aro.org>
> > 
> > It is not possible to accurately correlate rcutorture output with that
> > of debugfs.  This patch therefore adds a debugfs file that prints out
> > the rcutorture version number, permitting easy correlation.
> 
> You can't accurately correlate debugfs values with each
> other, either, right?  The rcutorture version number can change between
> accesses to different debugfs files.

True, but this is OK given the use case.

The problem that I used to have was that an automated test run would get
a grace-period hang somewhere in the middle of a long run.  Now, in a
grace-period hang, most of the interesting debugfs output is static,
so it is not necessary to line them up exactly.  All that is needed is
for the corellation to be good enough for me to ignore the debugfs
output that came a long time before the hang started.

Also, if there is an RCU grace-period hang, the rcutorture version number
will stop changing once it has the entire array waiting for a grace period,
which normally happens in a few seconds.

Make sense, or am I missing your point?

							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/