On Mon, Oct 03, 2011 at 03:46:11PM -0500, Christoph Lameter wrote: > 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. Wouldn't it be possible to pass a new flag to the metadata slab caches upon creation so that their locks could be placed in a separate lock class? Just allocate a separate lock_class_key structure for each such lock in that case, and then use lockdep_set_class_and_name to associate that structure with the corresponding lock. I do this in kernel/rcutree.c in order to allow the rcu_node tree's locks to nest properly. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>