Re: [Xen-devel] arm: alloc_heap_pages allocates already allocated page

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

On Wed, Feb 8, 2017 at 9:12 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>
>
> 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@xxxxxxx> wrote:
>>>>
>>>>
>>>> On 07/02/2017 13:25, Vijay Kilari wrote:
>>>>>
>>>>> On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall <julien.grall@xxxxxxx> 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@xxxxxxx>
>>> 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@xxxxxxx>
>>>     Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>     Tested-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
>>>
>>
>> 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;
>  }
>
  still I hit the error.

> 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

OK
>
> Cheers,
>
> --
> Julien Grall

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