Re: [Xen-devel] 4.11.0 RC1 panic

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> 05/22/18 1:01 PM >>>
>So far I've seen 2 stack traces with 4.11:
>(XEN) Xen call trace:
>(XEN)    [<ffff82d080284bd2>] mm.c#dec_linear_entries+0x12/0x20
>(XEN)    [<ffff82d08028922e>] mm.c#_put_page_type+0x13e/0x350
>(XEN)    [<ffff82d08023a00d>] _spin_lock+0xd/0x50
>(XEN)    [<ffff82d0802898af>] mm.c#put_page_from_l2e+0xdf/0x110
>(XEN)    [<ffff82d080288c59>] free_page_type+0x2f9/0x790
>(XEN)    [<ffff82d0802891f7>] mm.c#_put_page_type+0x107/0x350
>(XEN)    [<ffff82d0802898ef>] put_page_type_preemptible+0xf/0x10
>(XEN)    [<ffff82d080272adb>] domain.c#relinquish_memory+0xab/0x460
>(XEN)    [<ffff82d080276ae3>] domain_relinquish_resources+0x203/0x290
>(XEN)    [<ffff82d0802068bd>] domain_kill+0xbd/0x150
>(XEN)    [<ffff82d0802039e3>] do_domctl+0x7d3/0x1a90
>(XEN)    [<ffff82d080203210>] do_domctl+0/0x1a90
>(XEN)    [<ffff82d080367b95>] pv_hypercall+0x1f5/0x430
>(XEN)    [<ffff82d08036e422>] lstar_enter+0xa2/0x120
>(XEN)    [<ffff82d08036e42e>] lstar_enter+0xae/0x120
>(XEN)    [<ffff82d08036e422>] lstar_enter+0xa2/0x120
>(XEN)    [<ffff82d08036e42e>] lstar_enter+0xae/0x120
>(XEN)    [<ffff82d08036e422>] lstar_enter+0xa2/0x120
>(XEN)    [<ffff82d08036e42e>] lstar_enter+0xae/0x120
>(XEN)    [<ffff82d08036e48c>] lstar_enter+0x10c/0x120
>
>and
>(XEN)    [<ffff82d080284bd2>] mm.c#dec_linear_entries+0x12/0x20
>(XEN)    [<ffff82d08028922e>] mm.c#_put_page_type+0x13e/0x350
>(XEN)    [<ffff82d0802898af>] mm.c#put_page_from_l2e+0xdf/0x110
>(XEN)    [<ffff82d080288c59>] free_page_type+0x2f9/0x790
>(XEN)    [<ffff82d0802891f7>] mm.c#_put_page_type+0x107/0x350
>(XEN)    [<ffff82d0802898ef>] put_page_type_preemptible+0xf/0x10
>(XEN)    [<ffff82d080290b6d>] do_mmuext_op+0x73d/0x1810
>(XEN)    [<ffff82d080295630>] compat_mmuext_op+0x430/0x450
>(XEN)    [<ffff82d080367d4a>] pv_hypercall+0x3aa/0x430
>(XEN)    [<ffff82d08036bbf4>] entry_int82+0x74/0xc0
>(XEN)    [<ffff82d08036bbe8>] entry_int82+0x68/0xc0
>(XEN)    [<ffff82d08036bbf4>] entry_int82+0x74/0xc0
>(XEN)    [<ffff82d08036bbe8>] entry_int82+0x68/0xc0
>(XEN)    [<ffff82d08036bbf4>] entry_int82+0x74/0xc0
>(XEN)    [<ffff82d08036bbe8>] entry_int82+0x68/0xc0
>(XEN)    [<ffff82d08036bbf4>] entry_int82+0x74/0xc0
>(XEN)    [<ffff82d08036957e>] do_entry_int82+0x1e/0x20
>(XEN)    [<ffff82d08036bc31>] entry_int82+0xb1/0xc0
>
>both are from 4.11rc4

So I've been trying to look into this some more, and I've noticed an oddity in
the raw stack dump you had provided with the first report. Unfortunately you
didn't include that part for either of the above (the first one as being on a
different path would be of particular interest). Additionally, to be able to 
check
whether the (type_info) values on the stack really point at some anomaly, I'd
need the xen-syms (or xen.efi) from that same build of Xen. That'll allow me
to determine whether the values are simply leftovers from prior function
invocations. Otherwise, if they're live values, it'd be suspicious for
free_page_type() to be called on a page the type refcount of which is still 2.

As I assume that you don't have recorded/stored the additional bits I'm asking
for, I do realize that this means that unfortunately you'll have to obtain the 
data
another time. I'm sorry for that.


Two other questions on the internals of NetBSD page table management: Are all
updates to a given (set of) page table(s) fully serialized, e.g. via a 
respective
spin lock? Could you additionally point me at that code, or give an outline of
how the (un)pinning of L2 tables in the 32-bit case works?


Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel