Re: [Xen-devel] [xen-unstable test] 18426: tolerable FAIL - PUSHED

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.07.13 at 23:33, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 18426 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/18426/ 
> 
> Failures :-/ but no regressions.
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail like 
> 18423
>  test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install         fail like 
> 18424

So 8bfaa2c2 ("x86: add locking to map_pages_to_xen()") didn't
really help, but it's not yet clear to me what else is wrong here.

I'm in particular puzzled by the faulting address always being
ffff82c00020bxxx, never anything closer to the critical 2Mb
boundary.

And of course it doesn't help that I don't see this in any of my
own tests. So if anyone else has an idea, please share. If
nothing else, we may need to throw in a debugging patch to
track L2 page table population in the VMAP address range...

Or wait - I overlooked yesterday that vunmap() is also using
destroy_xen_mappings(), i.e. one of the races explicitly not
being dealt with by above change is still possible here. This
then needs to be switched to map_pages_to_xen(..., 0) too.
But then I wonder whether we shouldn't stop the attempt of
freeing intermediate page tables altogether, and short circuit
destroy_xen_mappings() into map_pages_to_xen(..., 0).

But before I propose a patch to do either of these, I'd really
like to understand which other (un)mapping it is that we race
with here (resulting - as pointed out above - in the fault being
at always the same virtual page frame).

Jan


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