Re: Trying to unmap invalid handle! pending_idx: @ drivers/net/xen-netback/netback.c:998 causes kernel panic/reboot

[Armin Zentai <armin.zentai@ezit.hu>]

Hi!

On 14/07/14 17:30, Zoltan Kiss wrote:
> On 14/07/14 13:14, Armin Zentai wrote:
>> Hi!
>>
>> On 14/07/14 13:54, Zoltan Kiss wrote:
>>> Hi,
>>>
>>> Based on the stack trace I think the guest sends packet with more than
>>> MAX_SKB_SLOTS slots, and one slot's grant mapping operation goes wrong.
>>> Then the error handling screws up the internal bookkeeping of pending
>>> slots, and tries to unmap something that is not mapped. Unfortunately it
>>> is quite complicated to emulate grant mapping failures in a predictable
>>> way.
>>> Armin, if we provide some patches (hopefully with a solution, but at
>>> least with some additional logging), would you be able to compile and
>>> verify it?
>>
>> I can compile and install it, the verification may take a few days.
>> We're building up a test system, and try to test with outgoing traffic.
>> If you have any advice, about how to test the new kernel, please share
>> with me (I mean large pps, or large bandwidth is the better, or try to
>> update/downgrade the GPLPV drivers to a specific version).
>>
>> I'm setting the loglevel to DBG.
>
> Also, if you have your vmlinux file, can you please run the following:
>
> addr2line -e <your vmlinux file> ffffffffa02622fc
>
> That would hopefully point out where xenvif_idx_unmap were called in
> check_gop, as it has 3 call sites.
>

I've run it on the vmlinux file, that I've made with make vmlinux.

[root@c2-node16 linux-3.15.4]# addr2line -e vmlinux ffffffffa02622fc
??:0

I think it does not found anything.

At the time we've found one VM that crashes its hypervisor in every 
evening at the same time, this virtual machine is belongs to one of our 
clients, but I'll try to get some info about a scheduled job or 
something that starts in that time.

> Zoli
>

Thanks,
  - Armin