Messages in this thread | | | Date | Thu, 13 Jul 2006 20:35:06 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [patch] lockdep: annotate mm/slab.c |
| |
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/
| |