linux-kernel - Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock

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

Date:	Mon, 21 Jun 2010 09:46:14 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Kyle McMartin <kyle@...artin.ca>
Cc:	Tilman Schmidt <tilman@...p.cc>, linux-kernel@...r.kernel.org
Subject: Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

On Mon, Jun 21, 2010 at 06:14:26AM -0400, Kyle McMartin wrote:
> On Sun, Jun 20, 2010 at 08:16:05AM -0700, Paul E. McKenney wrote:
> > My kneejerk reaction is that PROVE_RCU is a developer tool, so I am
> > OK with it not being set by default in Rawhide.  Or have you seen good
> > value from (say) PROVE_LOCKING in Rawhide?
> 
> Hi Paul,
> 
> I'm fine with this, we try to enable debug options in rawhide in order
> to get the most out of bug reports/dmesgs that we can. We've definitely
> spotted a lot of lockdep reports by having it enabled for general
> desktop use cases (but as debugging has become more intensive, the perf
> loss from having it enabled is more costly.)
> 
> I suspect we'll be OK with PROVE_RCU off though.

Sounds good -- but please feel free to bug me about this again if it turns
out that you are seeing too many testing escapes from Rawhide into RHEL.
Until then, my thought is that PROVE_RCU testing should primarily be done
by developers on development trees.

							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/