[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 02 May 2011 13:13:00 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 02 May 2011 05:14:25 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=iHIqZxAolMiM9/okBd47cqbPoVz/thpcwZB0OF7p2c4Dbx2nL1rUfbwF+lh57G3lmd dYHk44IADOpOKjbPZ2yj9sR3XjfJPkP2hOx22IUAyrX4Gb/BL/GdEyDer9f1NIdrgOQG U72kPKsAQefxzr196cmyKJBEVF867K6kbNbtQ=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwIwkdP9tlAzJdzIkehI+fT8ktT2A==
  • Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

On 02/05/2011 13:00, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> (2) Change the xmalloc lock to spin_lock_irqsave(). This would also have to
>> be transitively applied to at least the heap_lock in page_alloc.c. One issue
>> with this (and indeed with calling alloc_heap_pages at all with IRQs
>> disabled) is that alloc_heap_pages does actually assume IRQs are enabled
>> (for example, it calls flush_tlb_mask()) -- actually I think this limitation
>> probably predates the tsc rendezvous changes, and could be a source of
>> latent bugs in earlier Xen releases.
> (2b) Make only the xmalloc() lock disable IRQs, and don't allow it to
> go into the page allocator when IRQs were disabled on entry. Have
> a reserve page available on each pCPU (requires that in a single
> hypercall there can't be allocations adding up to more than PAGE_SIZE),
> and when consumed, re-fill this page e.g. from a softirq or tasklet.

You'd have to release/acquire the xmalloc lock across the ->get_mem call.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.