Messages in this thread | | | Date | Wed, 21 Jan 2009 08:19:50 +0100 | From | Nick Piggin <> | Subject | Re: lockdep and debug objects together are broken? |
| |
On Tue, Jan 20, 2009 at 10:11:47PM +0100, Vegard Nossum wrote: > On Tue, Jan 20, 2009 at 9:55 AM, Nick Piggin <npiggin@suse.de> wrote: > > Hi, > > > > I've had a problem frustrating my testing because lockdep was silently turning > > itself off... I patched out the code to disable lockdep after the first error, > > and it started showing up weird errors. kernel/fork.c:990 seemed to be the > > first to trigger (hard irqs disabled) from a call_usermodehelper call. Later, > > migration thread was reported to try to unlock rq->lock although it was > > holding no locks. Then init was reported to return to userspace without > > releasing an objectdebug hash lock. > > > > All that went away and everything seemed to work properly with debug objects > > configured out. > > > > I didn't get too far in trying to debug the problem. But it should be easy > > enough to reproduce (if not, I can post traces or test patches). > > I just built a kernel with lockdep and debugobjects enabled, and > everything seemed fine. I think you should post your kernel version, > config, and the lockdep patch (if needed -- it didn't seem to turn > itself off here).
Are you sure? Ie. sysrq+D a still works properly? In that case, you wouldn't need the lockdep patch because it just prevents the feature from being switched off.
I'll have to dig a bit further, then. The annoying thing is that lockdep turns itself off at the drop of a hat (and this particular problem seems to happen without any backtraces), so it invalidates all your lockdep testing if you don't realise it has turned itself off.
Is there a way to re-arm lockdep? That would be neat.
| |