linux-kernel - Re: lockdep recursive locking detected (rcu_kthread / __cache

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]

Message-ID: <alpine.DEB.2.00.1110031540560.11713@router.home>
Date:	Mon, 3 Oct 2011 15:46:11 -0500 (CDT)
From:	Christoph Lameter <cl@...two.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Sitsofe Wheeler <sitsofe@...oo.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	penberg@...nel.org, mpm@...enic.com, linux-mm@...ck.org
Subject: Re: lockdep recursive locking detected (rcu_kthread /
 __cache_free)

On Mon, 3 Oct 2011, Paul E. McKenney wrote:

> The first lock was acquired here in an RCU callback.  The later lock that
> lockdep complained about appears to have been acquired from a recursive
> call to __cache_free(), with no help from RCU.  This looks to me like
> one of the issues that arise from the slab allocator using itself to
> allocate slab metadata.

Right. However, this is a false positive since the slab cache with
the metadata is different from the slab caches with the slab data. The slab
cache with the metadata does not use itself any metadata slab caches.

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