linux-kernel - Re: [PATCH tip/core/urgent] fix several lockdep splats, allow multiple splats

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, 30 Apr 2010 15:09:17 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Valdis.Kletnieks@...edu, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	dhowells@...hat.com, eric.dumazet@...il.com
Subject: Re: [PATCH tip/core/urgent] fix several lockdep splats, allow
	multiple splats

* Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> On Fri, Apr 30, 2010 at 02:12:01PM -0400, Mathieu Desnoyers wrote:
> > * Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> > > On Fri, Apr 30, 2010 at 12:16:45PM -0400, Valdis.Kletnieks@...edu wrote:
> > > > On Fri, 30 Apr 2010 11:33:34 EDT, Mathieu Desnoyers said:
> > > > 
> > > > > I recommend creating a kernel command line parameter that would tweak
> > > > > the number of messages printed by lockdep. The default would indeed by 1
> > > > > message, but people in a debugging marathon can specify a larger value
> > > > > so they won't have to reboot between each individual lockdep error.
> > > > 
> > > > Yeah, that would rock for development kernels - playing whack-a-mole with
> > > > a half-dozen new lockdep whinges can easily stretch out for quite some time.
> > > 
> > > The RCU-lockdep splats are a bit different in nature than the
> > > deadlock-related splats that lockdep normally prints.  The RCU-lockdep
> > > splats are transient in nature, and it is easy to apply WARN_ON_ONCE().
> > > In contrast, if you permit multiple deadlock-related lockdep splats,
> > > you tend to get lots of warnings about the same deadlock cycle.
> > > 
> > > So how about an additional kernel configuration variable, default
> > > disabled, perhaps named CONFIG_PROVE_RCU_MULTIPLE, that allows a
> > > single boot to see multiple messages?  Unlike the dyntick-idle
> > > WARN_ON()s that generated multi-gigabyte console logs in a great
> > > hurry, I haven't yet seen excessive quantities of RCU-lockdep splats,
> > > so I don't see the need for an integer limit.
> > > 
> > > Thoughts?
> > 
> > Ideally we don't want to flood the console with thousands of instances
> > of the same RCU-lockdep splat (think of a missing read lock on a common
> > code path). Therefore I think keeping an integer limit is relevant here.
> > I agree that this integer limit could be selected by a CONFIG_ option
> > rather than by a kernel parameter, as it will typically only be used on
> > development kernels with "kernel hacking" enabled anyway. There is not
> > much point in bloating the kernel code with an extra debug-only kernel
> > parameter parsing.
> 
> We already limit via WARN_ON_ONCE(), and there are fewer than 500 lines
> of code in the kernel that can give RCU lockdep splats, so I really believe
> that we are OK without an overall limit for the foreseeable future.

Your idea makes sense then.

Thanks,

Mathieu

> 
> 							Thanx, Paul

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/