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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
