Re: [Xen-devel] 4.11.0 RC1 panic

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> 06/10/18 1:30 PM >>>
>When a new set of page tables is needed (this is pmap_create()), a pdp is
>requested from a cache.  If the cache is empty, pages are allocated in
>pmap_pdp_ctor(), which is going to also pin the L2 pages.
>When the page table is not needed any more (this is pmap_destroy()),
>the pdp is returned to the cache.  L2 pages remains pinned, with pointers to
>the kernel L1 pages.  If memory needs to be reclaimed from the cache,
>or is an explicit call to pool_cache_destruct_object() is done, 
>the L2 pages are unpinned, but they are not explicitely zeroed out before
>(can this be a problem ?).

I don't think so, no. Whatever is still in there is going to have respective
refcounts dropped while unvalidating the L2.

But I conclude that if there is an L2 unpin, that L2 is not expected to be in 
use
(as an L2) anywhere anymore, i.e. the only type reference is supposed to be
the one associated with the pinned status. Nor is it expected for L2s to ever
get freed by other means than unpinning (i.e. by them being taken off an L3).
If that's the case, maybe there is a way to place some more (NetBSD-specific)
assertions in a few places ...


What about L2 tables to be used in slot 3 of an L3 table? Aiui Xen won't allow
them to be pinned, hence I'd expect there to be some special casing in your
code. Considering no similar issues have been observed with 64-bit guests,
this one special case looks to me to be the prime suspect for something going
wrong (in Xen).


Jan


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