qeustion: a panic in __do_update_va_mapping()

qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

Hi Andrew, 

When I run some application with Xen, I encounter a Panic with log as the bottom of this email.
I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept: don't unmap the EPT pagetable while it is still in use'.

_iiuc_, in __do_update_va_mapping(),

'va' is unmapped before to call flush_tlb_one_mask(.., va).

Specifically, 
va is related to pl1e, pl1e = guest_map_l1e(va, &gl1mfn)...

but va is unmapped here:
out:
    if ( pl1e )
        guest_unmap_l1e(pl1e);

...

Before to call flush_tlb_one_mask(..., va);

Is it right?
Also, I wonder whether I need to move 'put_page(gl1pg)' to the bottom of __do_update_va_mapping().


(XEN) Xen call trace:
(XEN)    [<ffff82c480140223>] panic+0xc3/0x1a0
(XEN)    [<ffff82c48015832a>] invalidate_interrupt+0x2a/0x30
(XEN)    [<ffff82c480126f62>] symbols_lookup+0x22/0x2a0
(XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
(XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
(XEN)    [<ffff82c48012750a>] __print_symbol+0x8a/0xc0
(XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
(XEN)    [<ffff82c48018d5d0>] show_stack+0x110/0x180
(XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
(XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
(XEN)    [<ffff82c48018e414>] do_invalid_op+0x394/0x420
(XEN)    [<ffff82c48021e093>] ept_set_entry+0x4d3/0x820
(XEN)    [<ffff82c480221898>] handle_exception_saved+0x30/0x6e

(XEN)    [<ffff82c4801186b4>] alloc_heap_pages+0x5f4/0x600
(XEN)    [<ffff82c480118130>] alloc_heap_pages+0x70/0x600
(XEN)    [<ffff82c480118734>] alloc_domheap_pages+0x74/0x120
(XEN)    [<ffff82c4801144db>] do_memory_op+0x11db/0x2a40
(XEN)    [<ffff82c4801772ab>] get_page_type+0xb/0x20
(XEN)    [<ffff82c480177462>] get_page_from_l1e+0x1a2/0x680
(XEN)    [<ffff82c480173209>] is_iomem_page+0x9/0x80
(XEN)    [<ffff82c48017a655>] mod_l1_entry+0x1f5/0x720
(XEN)    [<ffff82c4801851dc>] flush_area_mask+0x7c/0x140
(XEN)    [<ffff82c48017ca53>] __do_update_va_mapping+0x453/0x7a0
(XEN)    [<ffff82c480226161>] do_iret+0xc1/0x1a0
(XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 30:
(XEN) Xen BUG at page_alloc.c:429
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...



Quan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Andrew Cooper]

On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
> Hi Andrew, 
>
> When I run some application with Xen, I encounter a Panic with log as the bottom of this email.
> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept: don't unmap the EPT pagetable while it is still in use'.

Its not the same.  My fix was for a pagefault.  Your crash is hitting a
BUG()

You need to investigate which BUG() is being hit (you are clearly not
using staging, as page_alloc.c:429 is outside of a function), and why.

~Andrew

>
> _iiuc_, in __do_update_va_mapping(),
>
> 'va' is unmapped before to call flush_tlb_one_mask(.., va).
>
> Specifically, 
> va is related to pl1e, pl1e = guest_map_l1e(va, &gl1mfn)...
>
> but va is unmapped here:
> out:
>     if ( pl1e )
>         guest_unmap_l1e(pl1e);
>
> ...
>
> Before to call flush_tlb_one_mask(..., va);
>
> Is it right?
> Also, I wonder whether I need to move 'put_page(gl1pg)' to the bottom of __do_update_va_mapping().
>
>
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480140223>] panic+0xc3/0x1a0
> (XEN)    [<ffff82c48015832a>] invalidate_interrupt+0x2a/0x30
> (XEN)    [<ffff82c480126f62>] symbols_lookup+0x22/0x2a0
> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
> (XEN)    [<ffff82c48012750a>] __print_symbol+0x8a/0xc0
> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
> (XEN)    [<ffff82c48018d5d0>] show_stack+0x110/0x180
> (XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
> (XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
> (XEN)    [<ffff82c48018e414>] do_invalid_op+0x394/0x420
> (XEN)    [<ffff82c48021e093>] ept_set_entry+0x4d3/0x820
> (XEN)    [<ffff82c480221898>] handle_exception_saved+0x30/0x6e
>
> (XEN)    [<ffff82c4801186b4>] alloc_heap_pages+0x5f4/0x600
> (XEN)    [<ffff82c480118130>] alloc_heap_pages+0x70/0x600
> (XEN)    [<ffff82c480118734>] alloc_domheap_pages+0x74/0x120
> (XEN)    [<ffff82c4801144db>] do_memory_op+0x11db/0x2a40
> (XEN)    [<ffff82c4801772ab>] get_page_type+0xb/0x20
> (XEN)    [<ffff82c480177462>] get_page_from_l1e+0x1a2/0x680
> (XEN)    [<ffff82c480173209>] is_iomem_page+0x9/0x80
> (XEN)    [<ffff82c48017a655>] mod_l1_entry+0x1f5/0x720
> (XEN)    [<ffff82c4801851dc>] flush_area_mask+0x7c/0x140
> (XEN)    [<ffff82c48017ca53>] __do_update_va_mapping+0x453/0x7a0
> (XEN)    [<ffff82c480226161>] do_iret+0xc1/0x1a0
> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 30:
> (XEN) Xen BUG at page_alloc.c:429
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
>
> Quan
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 01, 2016 7:16 PM, Andrew Cooper < andrew.cooper3@citrix.com > wrote:
>On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>> Hi Andrew,
>>
>> When I run some application with Xen, I encounter a Panic with log as the
>bottom of this email.
>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
>don't unmap the EPT pagetable while it is still in use'.
>
>Its not the same.  My fix was for a pagefault.  Your crash is hitting a
>BUG()
>
>You need to investigate which BUG() is being hit (you are clearly not using staging,
>as page_alloc.c:429 is outside of a function), and why.
>

It is not using staging, a internal version, but the __do_update_va_mapping() is the same..
So I think it is similar to staging.

Quan


>~Andrew
>
>>
>> _iiuc_, in __do_update_va_mapping(),
>>
>> 'va' is unmapped before to call flush_tlb_one_mask(.., va).
>>
>> Specifically,
>> va is related to pl1e, pl1e = guest_map_l1e(va, &gl1mfn)...
>>
>> but va is unmapped here:
>> out:
>>     if ( pl1e )
>>         guest_unmap_l1e(pl1e);
>>
>> ...
>>
>> Before to call flush_tlb_one_mask(..., va);
>>
>> Is it right?
>> Also, I wonder whether I need to move 'put_page(gl1pg)' to the bottom of
>__do_update_va_mapping().
>>
>>
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c480140223>] panic+0xc3/0x1a0
>> (XEN)    [<ffff82c48015832a>] invalidate_interrupt+0x2a/0x30
>> (XEN)    [<ffff82c480126f62>] symbols_lookup+0x22/0x2a0
>> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
>> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
>> (XEN)    [<ffff82c48012750a>] __print_symbol+0x8a/0xc0
>> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
>> (XEN)    [<ffff82c48018d5d0>] show_stack+0x110/0x180
>> (XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
>> (XEN)    [<ffff82c4801186b6>] alloc_heap_pages+0x5f6/0x600
>> (XEN)    [<ffff82c48018e414>] do_invalid_op+0x394/0x420
>> (XEN)    [<ffff82c48021e093>] ept_set_entry+0x4d3/0x820
>> (XEN)    [<ffff82c480221898>] handle_exception_saved+0x30/0x6e
>>
>> (XEN)    [<ffff82c4801186b4>] alloc_heap_pages+0x5f4/0x600
>> (XEN)    [<ffff82c480118130>] alloc_heap_pages+0x70/0x600
>> (XEN)    [<ffff82c480118734>] alloc_domheap_pages+0x74/0x120
>> (XEN)    [<ffff82c4801144db>] do_memory_op+0x11db/0x2a40
>> (XEN)    [<ffff82c4801772ab>] get_page_type+0xb/0x20
>> (XEN)    [<ffff82c480177462>] get_page_from_l1e+0x1a2/0x680
>> (XEN)    [<ffff82c480173209>] is_iomem_page+0x9/0x80
>> (XEN)    [<ffff82c48017a655>] mod_l1_entry+0x1f5/0x720
>> (XEN)    [<ffff82c4801851dc>] flush_area_mask+0x7c/0x140
>> (XEN)    [<ffff82c48017ca53>] __do_update_va_mapping+0x453/0x7a0
>> (XEN)    [<ffff82c480226161>] do_iret+0xc1/0x1a0
>> (XEN)    [<ffff82c480221408>] syscall_enter+0x88/0x8d
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 30:
>> (XEN) Xen BUG at page_alloc.c:429
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>>
>>
>> Quan
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Andrew Cooper]

On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
> On November 01, 2016 7:16 PM, Andrew Cooper < andrew.cooper3@citrix.com > wrote:
>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>> Hi Andrew,
>>>
>>> When I run some application with Xen, I encounter a Panic with log as the
>> bottom of this email.
>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
>> don't unmap the EPT pagetable while it is still in use'.
>>
>> Its not the same.  My fix was for a pagefault.  Your crash is hitting a
>> BUG()
>>
>> You need to investigate which BUG() is being hit (you are clearly not using staging,
>> as page_alloc.c:429 is outside of a function), and why.
>>
> It is not using staging, a internal version, but the __do_update_va_mapping() is the same..
> So I think it is similar to staging.

__do_update_va_mapping() is not relevant.  Your problem is in
alloc_heap_pages(), not __do_update_va_mapping().

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 01, 2016 7:41 PM, Andrew Cooper <andrew.cooper3@citrix.com > wrote:
>On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:16 PM, Andrew Cooper <
>andrew.cooper3@citrix.com > wrote:
>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>> Hi Andrew,
>>>>
>>>> When I run some application with Xen, I encounter a Panic with log
>>>> as the
>>> bottom of this email.
>>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
>>> don't unmap the EPT pagetable while it is still in use'.
>>>
>>> Its not the same.  My fix was for a pagefault.  Your crash is hitting
>>> a
>>> BUG()
>>>
>>> You need to investigate which BUG() is being hit (you are clearly not
>>> using staging, as page_alloc.c:429 is outside of a function), and why.
>>>
>> It is not using staging, a internal version, but the __do_update_va_mapping() is
>the same..
>> So I think it is similar to staging.
>
>__do_update_va_mapping() is not relevant.  Your problem is in
>alloc_heap_pages(), not __do_update_va_mapping().
>


Andrew, thanks for your help.. 

Check it, 
the BUG() is from
do_memory_op() -- alloc_domheap_pages() -- alloc_heap_pages()..
, not from  __do_update_va_mapping().

If so, I think the information is too limited to debug..

the BUG() is being hit at:
...
alloc_heap_pages()
    for ( i = 0; i < (1 << order); i++ )
    {
        /* Reference count must continuously be zero for free pages. */
        BUG_ON(pg[i].count_info != PGC_state_free);
...


I guess I hit a 'count_info == -1', more put_page() is called to return the page..

Quan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Andrew Cooper]

On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
> On November 01, 2016 7:41 PM, Andrew Cooper <andrew.cooper3@citrix.com > wrote:
>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>> andrew.cooper3@citrix.com > wrote:
>>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> When I run some application with Xen, I encounter a Panic with log
>>>>> as the
>>>> bottom of this email.
>>>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
>>>> don't unmap the EPT pagetable while it is still in use'.
>>>>
>>>> Its not the same.  My fix was for a pagefault.  Your crash is hitting
>>>> a
>>>> BUG()
>>>>
>>>> You need to investigate which BUG() is being hit (you are clearly not
>>>> using staging, as page_alloc.c:429 is outside of a function), and why.
>>>>
>>> It is not using staging, a internal version, but the __do_update_va_mapping() is
>> the same..
>>> So I think it is similar to staging.
>> __do_update_va_mapping() is not relevant.  Your problem is in
>> alloc_heap_pages(), not __do_update_va_mapping().
>>
>
> Andrew, thanks for your help.. 
>
> Check it, 
> the BUG() is from
> do_memory_op() -- alloc_domheap_pages() -- alloc_heap_pages()..
> , not from  __do_update_va_mapping().
>
> If so, I think the information is too limited to debug..
>
> the BUG() is being hit at:
> ...
> alloc_heap_pages()
>     for ( i = 0; i < (1 << order); i++ )
>     {
>         /* Reference count must continuously be zero for free pages. */
>         BUG_ON(pg[i].count_info != PGC_state_free);
> ...
>
>
> I guess I hit a 'count_info == -1', more put_page() is called to return the page..

Yes.  This means that you have a reference counting error elsewhere in
the hypervisor, and something is dropping too many references.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:41 PM, Andrew Cooper
><andrew.cooper3@citrix.com > wrote:
>>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>>> andrew.cooper3@citrix.com > wrote:
>>>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> When I run some application with Xen, I encounter a Panic with log
>>>>>> as the
>>>>> bottom of this email.
>>>>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22
>'x86/p2m-ept:
>>>>> don't unmap the EPT pagetable while it is still in use'.
>>>>>
>>>>> Its not the same.  My fix was for a pagefault.  Your crash is
>>>>> hitting a
>>>>> BUG()
>>>>>
>>>>> You need to investigate which BUG() is being hit (you are clearly
>>>>> not using staging, as page_alloc.c:429 is outside of a function), and why.
>>>>>
>>>> It is not using staging, a internal version, but the
>>>> __do_update_va_mapping() is
>>> the same..
>>>> So I think it is similar to staging.
>>> __do_update_va_mapping() is not relevant.  Your problem is in
>>> alloc_heap_pages(), not __do_update_va_mapping().
>>>
>>
>> Andrew, thanks for your help..
>>
>> Check it,
>> the BUG() is from
>> do_memory_op() -- alloc_domheap_pages() -- alloc_heap_pages()..
>> , not from  __do_update_va_mapping().
>>
>> If so, I think the information is too limited to debug..
>>
>> the BUG() is being hit at:
>> ...
>> alloc_heap_pages()
>>     for ( i = 0; i < (1 << order); i++ )
>>     {
>>         /* Reference count must continuously be zero for free pages. */
>>         BUG_ON(pg[i].count_info != PGC_state_free); ...
>>
>>
>> I guess I hit a 'count_info == -1', more put_page() is called to return the page..
>
>Yes.  This means that you have a reference counting error elsewhere in
>the hypervisor, and something is dropping too many references.
>

:(:(..
Any method to address it? 

Quan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Andrew Cooper]

On 01/11/16 12:07, Xuquan (Quan Xu) wrote:
> On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>> On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>>> On November 01, 2016 7:41 PM, Andrew Cooper
>> <andrew.cooper3@citrix.com > wrote:
>>>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>>>> andrew.cooper3@citrix.com > wrote:
>>>>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> When I run some application with Xen, I encounter a Panic with log
>>>>>>> as the
>>>>>> bottom of this email.
>>>>>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22
>> 'x86/p2m-ept:
>>>>>> don't unmap the EPT pagetable while it is still in use'.
>>>>>>
>>>>>> Its not the same.  My fix was for a pagefault.  Your crash is
>>>>>> hitting a
>>>>>> BUG()
>>>>>>
>>>>>> You need to investigate which BUG() is being hit (you are clearly
>>>>>> not using staging, as page_alloc.c:429 is outside of a function), and why.
>>>>>>
>>>>> It is not using staging, a internal version, but the
>>>>> __do_update_va_mapping() is
>>>> the same..
>>>>> So I think it is similar to staging.
>>>> __do_update_va_mapping() is not relevant.  Your problem is in
>>>> alloc_heap_pages(), not __do_update_va_mapping().
>>>>
>>> Andrew, thanks for your help..
>>>
>>> Check it,
>>> the BUG() is from
>>> do_memory_op() -- alloc_domheap_pages() -- alloc_heap_pages()..
>>> , not from  __do_update_va_mapping().
>>>
>>> If so, I think the information is too limited to debug..
>>>
>>> the BUG() is being hit at:
>>> ...
>>> alloc_heap_pages()
>>>     for ( i = 0; i < (1 << order); i++ )
>>>     {
>>>         /* Reference count must continuously be zero for free pages. */
>>>         BUG_ON(pg[i].count_info != PGC_state_free); ...
>>>
>>>
>>> I guess I hit a 'count_info == -1', more put_page() is called to return the page..
>> Yes.  This means that you have a reference counting error elsewhere in
>> the hypervisor, and something is dropping too many references.
>>
> :(:(..
> Any method to address it?

Not specifically.  It is similar to chasing a double free bug.

You should review whatever local additions you have in your tree extra
carefully.  It might be that there is a setup path which doesn't take a
ref, or a buggy error path which cleans up too many refs.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 01, 2016 9:21 PM, Andrew Cooper wrote:
>On 01/11/16 12:07, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>>> On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>>>> On November 01, 2016 7:41 PM, Andrew Cooper
>>> <andrew.cooper3@citrix.com > wrote:
>>>>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>>>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>>>>> andrew.cooper3@citrix.com > wrote:
>>>>>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> When I run some application with Xen, I encounter a Panic with
>>>>>>>> log as the
>>>>>>> bottom of this email.
>>>>>>>> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22
>>> 'x86/p2m-ept:
>>>>>>> don't unmap the EPT pagetable while it is still in use'.
>>>>>>>
>>>>>>> Its not the same.  My fix was for a pagefault.  Your crash is
>>>>>>> hitting a
>>>>>>> BUG()
>>>>>>>
>>>>>>> You need to investigate which BUG() is being hit (you are clearly
>>>>>>> not using staging, as page_alloc.c:429 is outside of a function), and why.
>>>>>>>
>>>>>> It is not using staging, a internal version, but the
>>>>>> __do_update_va_mapping() is
>>>>> the same..
>>>>>> So I think it is similar to staging.
>>>>> __do_update_va_mapping() is not relevant.  Your problem is in
>>>>> alloc_heap_pages(), not __do_update_va_mapping().
>>>>>
>>>> Andrew, thanks for your help..
>>>>
>>>> Check it,
>>>> the BUG() is from
>>>> do_memory_op() -- alloc_domheap_pages() -- alloc_heap_pages()..
>>>> , not from  __do_update_va_mapping().
>>>>
>>>> If so, I think the information is too limited to debug..
>>>>
>>>> the BUG() is being hit at:
>>>> ...
>>>> alloc_heap_pages()
>>>>     for ( i = 0; i < (1 << order); i++ )
>>>>     {
>>>>         /* Reference count must continuously be zero for free pages. */
>>>>         BUG_ON(pg[i].count_info != PGC_state_free); ...
>>>>
>>>>
>>>> I guess I hit a 'count_info == -1', more put_page() is called to return the
>page..
>>> Yes.  This means that you have a reference counting error elsewhere
>>> in the hypervisor, and something is dropping too many references.
>>>
>> :(:(..
>> Any method to address it?
>
>Not specifically.  It is similar to chasing a double free bug.
>
>You should review whatever local additions you have in your tree extra carefully.
>It might be that there is a setup path which doesn't take a ref, or a buggy error
>path which cleans up too many refs.
>

Andrew, thank you very much!!
I think it is likely a buggy error of local additions..

Quan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Jan Beulich]

>>> On 03.11.16 at 13:14, <xuquan8@huawei.com> wrote:
> Jan,
> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer to 
> https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&package= 
> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5     ??

Judging from the name, I guess so. But this has been ages ago.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 03, 2016 9:18 PM, < JBeulich@suse.com > wrote:
>>>> On 03.11.16 at 13:14, <xuquan8@huawei.com> wrote:
>> Jan,
>> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer
>> to
>https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&pack
>age=
>> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5     ??
>
>Judging from the name, I guess so. But this has been ages ago.
>

Thanks. btw, if you still recall, could you share how to fix this BUG_ON? 

 Yes, It is really ages ago, thanks again.

Quan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: qeustion: a panic in __do_update_va_mapping()

[Jan Beulich]

>>> On 03.11.16 at 14:27, <xuquan8@huawei.com> wrote:
> On November 03, 2016 9:18 PM, < JBeulich@suse.com > wrote:
>>>>> On 03.11.16 at 13:14, <xuquan8@huawei.com> wrote:
>>> Jan,
>>> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer
>>> to
>>https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&pack 
>>age=
>>> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5     ??
>>
>>Judging from the name, I guess so. But this has been ages ago.
>>
> 
> Thanks. btw, if you still recall, could you share how to fix this BUG_ON? 

Well, you did find the fix for the issue back then; yours then is
a different one pretty certainly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel