Re: arm: alloc_heap_pages allocates already allocated page

[Julien Grall <julien.grall@arm.com>]

On 08/02/17 14:18, Julien Grall wrote:
> Hi,
> 
> On 07/02/17 15:59, Vijay Kilari wrote:
>> On Tue, Feb 7, 2017 at 6:57 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>>
>>> On 07/02/2017 13:25, Vijay Kilari wrote:
>>>>
>>>> On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>>>
>>>>>
>>>>> One more thing, if Xen 4.7 was able to go up to booting Dom0 without any
>>>>> patches on a NUMA board. I would recommend to try to bisect and see if
>>>>> you
>>>>> can find an offending commit.
>>>>
>>>>
>>>>   Yes, with plain 4.7 panic is not seen
>>>
>>>
>>> Can you please bisect Xen? It could save us a bit of time to understand
>>> what's going on.
>>
>> ubuntu@ubuntu:~/xen_upstream_new/xen$ git bisect bad
>> 493f535a06b5b4041c0745e954780dd5d6f80581 is the first bad commit
>> commit 493f535a06b5b4041c0745e954780dd5d6f80581
>> Author: Julien Grall <julien.grall@arm.com>
>> Date:   Thu Sep 15 12:28:36 2016 +0100
>>
>>     xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry
>>
>>     The function p2m_insert_mapping can be re-implemented using the generic
>>     function p2m_set_entry.
>>
>>     Note that the mapping is not reverted anymore if Xen fails to insert a
>>     mapping. This was added to ensure the MMIO are not kept half-mapped
>>     in case of failure and to follow the x86 counterpart. This was removed
>>     on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
>>     mappings" and I think we should let the caller taking care of it.
>>
>>     Finally drop the operation INSERT in apply_* as nobody is using it
>>     anymore. Note that the functions could have been dropped in one go at the
>>     end, however I find easier to drop the operations one by one avoiding a
>>     big deletion in the patch that convert the last operation.
>>
>>     Signed-off-by: Julien Grall <julien.grall@arm.com>
>>     Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>     Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
>>
> 
> I think I have managed to reproduce the crash at boot time though the stack
> trace is different (see below). This sounds like to me a memory corruption,
> I will dig down and see what I can find.

Hmmm after all the issue might be different. My DT was describing some
LPIs but Xen had no check. So we ended up to overrun the buffer.

This hack patch should tell whether you have LPIs described in your DT:

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..0631441 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -238,6 +238,10 @@ int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
     if ( out_type )
         *out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
 
+    /* Be crude for now */
+    if ( *out_hwirq > 1024 )
+        return -EINVAL;
+
     return 0;
 }

If you hit an error, I would recommend to drop them. If not and still have the issue
few things I would recommend to try:
	- A different compiler version
	- Look at the state of the heap everytime you allocate/free a page

Cheers,

-- 
Julien Grall

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