Re: [PATCH tip/core/urgent] fix several lockdep splats, allowmultiple splats

[Mathieu Desnoyers]

* Paul E. McKenney (paulmck@xxxxxxxxxxxxxxxxxx) wrote:
> On Fri, Apr 30, 2010 at 12:16:45PM -0400, Valdis.Kletnieks@xxxxxx 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.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/