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

Re: [Xen-devel] [PATCH] x86: fix domain cleanup

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Tue, 28 Oct 2008 11:15:28 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 28 Oct 2008 04:16:01 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ack46tyFG1+8hKTeEd2ghgAX8io7RQAA57YJ
  • Thread-topic: [Xen-devel] [PATCH] x86: fix domain cleanup

On 28/10/08 10:49, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> Will do it that way for submission. In testing it with that code inlined in
>> __put_page_type(), I can confirm that this closes the memory leak, but
>> it (obviously) doesn't address the crash when encountering a PGT_partial
>> page hanging off of a page table being cleaned up by that explicit call
>> to free_page_type() getting executed as a side effect of
>> DOMAIN_DESTRUCT_AVOID_RECURSION. The question of course really
>> is whether it's worthwhile trying to fix that, or rather to do away with it
>> altogether by utilizing the 'real' preemption.
> I don't actually understand the AVOID_RECURSION logic in
> relinquish_memory(). I'd be delighted to get rid of it.

Actually I'm not sure how PGT_partial reference counting works either. Do
such pages hold a general reference count? It appears not, so I don't see
why for example we couldn't have the put_page() in
get_page_and_type_from_pagenr() cause free_domheap_pages() and then BUG_ON()
the fact that the type count is non-zero (because it is partially

Shouldn't free_domheap_pages() do cleanup for partially validated pages?

Is it possible or necessary to tell the difference between a page that is
partially alloc_page_type()d versus one which is partially
free_page_type()d? (e.g., are the reference counts left in different states
in each case, and does that matter?)

 -- Keir

Xen-devel mailing list



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