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:	Wed, 25 Jan 2012 17:57:46 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Steffen Persvold <sp@...ascale.com>
Cc:	Daniel J Blueman <daniel@...ascale-asia.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: RCU qsmask !=0 warnings on large-SMP...

On Wed, Jan 25, 2012 at 11:51:08PM +0100, Steffen Persvold wrote:
> On 1/25/2012 22:51, Paul E. McKenney wrote:
> >On Wed, Jan 25, 2012 at 09:35:15PM +0100, Steffen Persvold wrote:
> []
> >>
> >>Yes, 3.2.1 is our debug target right now.
> >
> >OK, good!  Could you please add an "ftrace_dump(DUMP_ALL)" before you
> >print the first set of error messages?  (Preferably set up so that
> >you only dump once!)
> >
> >Then before you start testing, could you please enable the
> >rcu_grace_period and rcu_grace_period_init trace events?  This should
> >get a good picture of the sequence of grace-period-related events leading
> >up to the failure.
> >
> >You will need to build the kernel with CONFIG_RCU_TRACE=y.
> >
> >The usual commands suffice to enable tracing:
> >
> >	echo 1>  /sys/kernel/debug/tracing/events/rcu_grace_period/enable
> >	echo 1>  /sys/kernel/debug/tracing/events/rcu_grace_period_init/enable
> >
> >This should give some history that might help understand why the previous
> >grace period ended before the CPUs had all checked in.  Maybe even why
> >the rcu_node structures got advance notice of the new grace period...
> >
> 
> []
> 
> >>
> >>Are you talking about the data from /sys/kernel/debug/rcu/ ? I have
> >>CONFIG_RCU_TRACE (and consequently CONFIG_TREE_RCU_TRACE) set, is
> >>this enough to get the event data you want ?
> >
> >Yep, if you have CONFIG_RCU_TRACE=y, then the two tracepoints should
> >be available.
> >
> 
> It seems that I don't have the /sys/kernel/debug/tracing/events
> interface on the kernel I'm running now. Perhaps I need to enable
> the CONFIG_FTRACE feature also ? If so what FTRACE interfaces do I
> need ?

Hmmm...  Defaults to "enabled" in both my Power and KVM configs.

Please see attached for one of my KVM-based .config files that got
me trace events (but only the utilization-based default ones because
this particular run had CONFIG_RCU_TRACE=n -- you will also need
CONFIG_RCU_TRACE=y).

I believe that CONFIG_PERF_EVENTS=y is required.

							Thanx, Paul

View attachment ".config" of type "text/plain" (79387 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ