Messages in this thread |  | | | Subject | Re: [BUG] Lockdep recursive locking in kmem_cache_free | | From | Thomas Gleixner <> | | Date | Fri, 28 Jul 2006 23:20:08 +0200 |
| |
On Fri, 2006-07-28 at 14:12 -0700, Ravikiran G Thirumalai wrote: > On Fri, Jul 28, 2006 at 01:48:33PM -0700, Christoph Lameter wrote: > > On Fri, 28 Jul 2006, Thomas Gleixner wrote: > > > > > On Fri, 2006-07-28 at 13:36 -0700, Christoph Lameter wrote: > > > > On Fri, 28 Jul 2006, Thomas Gleixner wrote: > > > > > > > > > Let me know, if you need more info > > > > > > > > What type of NUMA system is this? How many nodes? Is memory exhausted on > > > > some so that allocations are redirected? Are cpusets or memory policies > > > > used to redirect allocations? > > > > > > Dual dual core opteron board, only one CPU brought up. This happens > > > during bootup, so no special settings involved. > > > > One cpu with two nodes? > > > > > [ 0.000000] Bootmem setup node 0 0000000000000000-0000000080000000 > > > [ 0.000000] Bootmem setup node 1 0000000080000000-00000000fbff0000 > > > > Right two nodes. We may have a special case here of one cpu having to > > manage remote memory. Alien cache freeing is likely screwed up in that > > case because we cannot have the idea of one processor local to the node > > doing the alien cache draining . We have to take the remote lock (no cpu > > dedicate to that node). > > Why should there be any problem taking the remote l3 lock? If the remote > node does not have cpu that does not mean we cannot take a lock from the > local node!!! > > I think current git does not teach lockdep to ignore recursion for > array_cache->lock when the array_cache->lock are from different cases. As > Arjan pointed out, I can see that l3->list_lock is special cased, but I > cannot find where array_cache->lock is taken care of. > > Again, if this is indeed a problem (recursion) machine should not boot even, > when compiled without lockdep, tglx, can you please verify this?
It boots witjh lockdep disabled, so lockdep needs some education, which is not that easy in this case.
tglx
- 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/
|  |