linux-kernel - Re: kmemleak: Protect the seq start/next/stop sequence by rcu_read

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:	Tue, 11 Aug 2009 09:32:05 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: kmemleak: Protect the seq start/next/stop sequence by
	rcu_read_lock()


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

> On Mon, 2009-08-10 at 20:45 +0200, Ingo Molnar wrote:
> > * Catalin Marinas <catalin.marinas@....com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/