From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien.grall@arm.com>,
Aaron Cornelius <Aaron.Cornelius@dornerworks.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: Xen 4.7 crash
Date: Wed, 1 Jun 2016 23:31:21 +0100 [thread overview]
Message-ID: <40a51386-8c50-d5b4-259e-ca577b86789f@citrix.com> (raw)
In-Reply-To: <f7916387-200e-8f8b-1820-4e23d4fc9367@arm.com>
On 01/06/2016 23:24, Julien Grall wrote:
> Hi,
>
> On 01/06/2016 22:35, Andrew Cooper wrote:
>> On 01/06/2016 20:54, Aaron Cornelius wrote:
>>> <snip>
>>> (XEN) Xen call trace:
>>> (XEN) [<0021fdd4>] free_domheap_pages+0x1c/0x324 (PC)
>>> (XEN) [<0025b0cc>] p2m_teardown+0xa0/0x108 (LR)
>>> (XEN) [<0025b0cc>] p2m_teardown+0xa0/0x108
>>> (XEN) [<0024f668>] arch_domain_destroy+0x20/0x50
>>> (XEN) [<0024f8f0>] arch_domain_create+0x258/0x284
>>> (XEN) [<0020854c>] domain_create+0x2dc/0x510
>>> (XEN) [<00206d6c>] do_domctl+0x5b4/0x1928
>>> (XEN) [<00260130>] do_trap_hypervisor+0x1170/0x15b0
>>> (XEN) [<00263b10>] entry.o#return_from_trap+0/0x4
>>> (XEN)
>>> (XEN)
>>> (XEN) ****************************************
>>> (XEN) Panic on CPU 0:
>>> (XEN) CPU0: Unexpected Trap: Data Abort
>>> (XEN)
>>> (XEN) ****************************************
>>> (XEN)
>>> (XEN) Reboot in five seconds...
>>
>> As for this specific crash itself, In the case of an early error path,
>> p2m->root can be NULL in p2m_teardown(), in which case
>> free_domheap_pages() will fall over in a heap. This patch should
>> resolve it.
>
> Good catch!
>
>>
>> @@ -1408,7 +1411,8 @@ void p2m_teardown(struct domain *d)
>> while ( (pg = page_list_remove_head(&p2m->pages)) )
>> free_domheap_page(pg);
>>
>> - free_domheap_pages(p2m->root, P2M_ROOT_ORDER);
>> + if ( p2m->root )
>> + free_domheap_pages(p2m->root, P2M_ROOT_ORDER);
>>
>> p2m->root = NULL;
>>
>> I would be tempted to suggest making free_domheap_pages() tolerate NULL
>> pointers, except that would only be a safe thing to do if we assert that
>> the order parameter is 0, which won't help this specific case.
>
> free_xenheap_pages already tolerates NULL (even if an order != 0). Is
> there any reason to not do the same for free_domheap_pages?
The xenheap allocation functions deal in terms of plain virtual
addresses, while the domheap functions deal in terms of struct page_info *.
Overall, this means that the domheap functions have a more restricted
input/output set than their xenheap variants.
As there is already precedent with xenheap, making domheap tolerate NULL
is probably fine, and indeed the preferred course of action.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-01 22:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 19:54 Xen 4.7 crash Aaron Cornelius
2016-06-01 20:00 ` Andrew Cooper
2016-06-01 20:45 ` Aaron Cornelius
2016-06-01 21:24 ` Andrew Cooper
2016-06-01 22:18 ` Julien Grall
2016-06-01 22:26 ` Andrew Cooper
2016-06-01 21:35 ` Andrew Cooper
2016-06-01 22:24 ` Julien Grall
2016-06-01 22:31 ` Andrew Cooper [this message]
2016-06-02 8:47 ` Jan Beulich
2016-06-02 8:53 ` Andrew Cooper
2016-06-02 9:07 ` Jan Beulich
2016-06-01 22:35 ` Julien Grall
2016-06-02 1:32 ` Aaron Cornelius
2016-06-02 8:49 ` Jan Beulich
2016-06-02 9:07 ` Julien Grall
2016-06-06 13:58 ` Aaron Cornelius
2016-06-06 14:05 ` Julien Grall
2016-06-06 14:19 ` Wei Liu
2016-06-06 15:02 ` Aaron Cornelius
2016-06-07 9:53 ` Ian Jackson
2016-06-07 13:40 ` Aaron Cornelius
2016-06-07 15:13 ` Aaron Cornelius
2016-06-09 11:14 ` Ian Jackson
2016-06-14 13:11 ` Aaron Cornelius
2016-06-14 13:15 ` Wei Liu
2016-06-14 13:26 ` Aaron Cornelius
2016-06-14 13:38 ` Aaron Cornelius
2016-06-14 13:47 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40a51386-8c50-d5b4-259e-ca577b86789f@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Aaron.Cornelius@dornerworks.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).