Re: kmemleak: Protect the seq start/next/stop sequence byrcu_read_lock()

[Ingo Molnar]

* Catalin Marinas <catalin.marinas@xxxxxxx> wrote:

> On Mon, 2009-08-10 at 20:45 +0200, Ingo Molnar wrote:
> > * Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> > 
> > > On Sun, 2009-08-02 at 13:14 +0200, Ingo Molnar wrote:
> > > > hm, some recent kmemleak patch is causing frequent hard and 
> > > > soft lockups in -tip testing (-rc5 based).
> > > 
> > > Thanks for reporting this. It shouldn't be caused by the patch 
> > > mentioned in the subject as this only deals with reading the seq 
> > > file which doesn't seem to be the case here.
> > 
> > Since i turned off kmemleak in -tip completely via the patch below i 
> > havent had a single such lockup.
> > 
> > Have you tried the config i sent - does it work fine for you? For me 
> > it locks up on various boxes within a couple of minutes - without 
> > doing anything particular beyond building a kernel or so.
> 
> I couldn't tried your config as I don't have an x86_64 machine (I 
> only rely on an x86_32 laptop at home and several ARM machines at 
> work for testing).
> 
> I tried similar config and with the mainline kernel I get some 
> lockups (several seconds) with CONFIG_PREEMPT disabled on ARM 
> machines or x86 during a scanning episode but it eventually 
> completes the scanning. With the kmemleak patches for the next 
> merging window, I don't get any lockups as it has more 
> cond_resched() calls.

How big are those patches? Kmemleak is new in .31 so if it fixes a 
real problem it might still be acceptable.

> Maybe on your x86_64 box you get some bigger objects allocated 
> (alloc_bootmem, per-cpu, data/bss, NODE_DATA, task stacks) which 
> are scanned without cond_resched() calls and CONFIG_PREEMPT 
> disabled. Scanning the memory can even take several minutes 
> especially with CONFIG_PROVE_LOCKING enabled and maybe that's why 
> you see the lockups. Enabling CONFIG_PREEMPT reduces the lockup 
> period.
> 
> I'll try tomorrow with x86_32 allyesconfig on my laptop and see 
> how it goes.

It could be a livelock not a true deadlock - but a pretty severe one 
at that.

	Ingo
--
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/