From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [Question] Is it safe to call "xmalloc()" with irq disabled? Date: Tue, 01 Mar 2011 08:16:08 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Haitao Shan , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Haitao, Both _xmalloc and xfree can only safely be called with irqs enabled. I know there is a somewhat suspicious area during CPU bringup where we temporarily disable spinlock debugging. It would be nice to not need this. And for this particular bug you are dealing with, perhaps we can fix it now -- what is the backtrace for the failing allocation? -- Keir On 01/03/2011 07:42, "Haitao Shan" wrote: > Hi, Keir, >=20 > In recent effort on debugging cpu offline/online, I met Xen panic some ti= mes. >=20 > The reason of the panic is caused by following code path: >=20 > xmalloc ---> alloc_heap_pages ---> flush_area_mask { > ASSERT(local_irq_enabled)........} >=20 > This bring me the question: is it safe to call xmalloc with local irq > disabled? As you can see, not all alloc_heap_pages will result in TLB > flushing. But once it calls, the assertion will fail. >=20 > In my case, the xmalloc is called with starting secondary processors. Som= e > initialization code run with local irq enabled, for example, the MCA > initialization. Normally this piece of code runs when all heap pages do n= ot > have a former owner (no domain is initialized at booting time, I guess), = so > calling xmalloc won't be a problem. But later when this same piece of cod= e > runs as a result of cpu online operation, it has=A0possibility=A0to trigger t= he > assertion failure. >=20 > What's you view on this, Keir? Is it the design that xmalloc must be call= ed > with local irq enabled? I have done a hack to remove the assertion. Every > things work just fine to me. But maybe I just happened not to run into an= y > problem with the hack. >=20 > Shan Haitao >=20