Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter <clameter@sgi.com>]

On Thu, 13 Jul 2006, Andrew Morton wrote:

> > 2.6.17 code has also the dropping of the lock.
> 
> It doesn't.

Ahh... mm patch in the way. This gets even stranger.
 
> > This was no reversion. 
> > Maybe there is a problem but then I'd like to hear about it:
> 
> It's all in this thread - see Chandra's testing results.

Hmmm. Chandra's traces are all over the place.

Ok. I found a series of cases where free_block is used on the shared 
array where the shared array can become corrupted if we drop the lock
in free_block():

1. cache_reap() calling drain_array (which calls free_block) on the shared 
  array

2. drain_cpu_caches() calling drain_array on the shared array.

3. cpuup_callback() in case CPU_UP_CANCELLED calling free_block

4. alloc_kmemlist() calling free_block().

The fix by removing the dropping of the lock in free_block could cause 
retaking the list_lock that we already hold in the OFF_SLAB case (even in 
the non NUMA case). 

However, we have not noticed this so far. Maybe we were lucky?

In the RCU case we only need to take the list lock when RCU runs to free 
the management object. So that is safe. Guess we never use non-RCU 
OFF_SLAB.

Alokk? Can you confirm this reasoning.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/