Messages in this thread |  | | | Date | Fri, 30 Apr 2010 11:02:47 -0700 | | From | "Paul E. McKenney" <> | | Subject | Re: [PATCH tip/core/urgent] fix several lockdep splats, allow multiple splats |
| |
On Fri, Apr 30, 2010 at 12:16:45PM -0400, Valdis.Kletnieks@vt.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?
Thanx, Paul
|  |