From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161306AbWG1VKv (ORCPT ); Fri, 28 Jul 2006 17:10:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161305AbWG1VKv (ORCPT ); Fri, 28 Jul 2006 17:10:51 -0400 Received: from server99.tchmachines.com ([72.9.230.178]:50890 "EHLO server99.tchmachines.com") by vger.kernel.org with ESMTP id S1161306AbWG1VKu (ORCPT ); Fri, 28 Jul 2006 17:10:50 -0400 Date: Fri, 28 Jul 2006 14:12:27 -0700 From: Ravikiran G Thirumalai To: Christoph Lameter Cc: Thomas Gleixner , Pekka Enberg , LKML , Ingo Molnar , Arjan van de Ven , alokk@calsoftinc.com Subject: Re: [BUG] Lockdep recursive locking in kmem_cache_free Message-ID: <20060728211227.GB3739@localhost.localdomain> References: <84144f020607272222o7b1d0270p997b8e3bf07e39e7@mail.gmail.com> <1154067247.27297.104.camel@localhost.localdomain> <1154117501.10196.2.camel@localhost.localdomain> <1154118476.10196.5.camel@localhost.localdomain> <1154118947.10196.10.camel@localhost.localdomain> <1154119658.10196.17.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server99.tchmachines.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - scalex86.org X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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? Thanks, Kiran