Re: [Xen-devel] xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Fri, Jun 05, 2009 at 11:20:17AM +0100, Ian Campbell wrote:
> On Thu, 2009-06-04 at 16:26 -0400, Pasi Kärkkäinen wrote:
> > What do you suggest me to try next? 
> 
> I'm at a bit of a loss to be honest...
> 
> It's interesting that it's always kswapd0 even in the case with no swap
> configured. Were you running with CONFIG_SWAP=n or just with the swap
> device turned off?
> 

I just ran "swapoff -a" before testing..

> Judging from the backtrace the sequence of events seems to be roughly:
> kswapd<0> runs and calls balance_pgdat which calls shrink_zone who in
> turn calls shrink_active_list if inactive_anon_is_low() (so I think we
> are dealing with anon pages). shrink_active_list() then iterates over a
> list of pages calling page_referenced() on each one. page_referenced()
> eventually calls down to page_referenced_one() (presumably via
> page_referenced_anon()) and eventually to page_check_address() which
> walks the page table and attempts to map the PTE page. This goes via
> pte_offset_map() to kmap_atomic_pte() then xen_kmap_atomic_pte(). Here
> we check if the page is pinned and then attempt to map it, since we
> _think_ the page is not pinned the mapping is writable. However at this
> point Xen reports that the page really is pinned (28000001 => Page Type
> 1 == L1 PT) and we are trying to make a writable mapping (e0000000 =>
> Page Type 7 == Writable) which is disallowed.
> 
> Do you know which line of xen_set_pte() the fault is occurring at? I
> assume either "ptep->pte_high =" or "ptep->pte_low =".
> 

I haven't looked for that.. I guess I should compile debug=y Xen build
again.

> So the question is -- how come we have a page which is pinned but this
> fact is not recorded in the struct page information? It might be
> interesting to know if the corresponding L3 PT is pinned. If the mm is
> active then this should always be the case and I _think_ it would be a
> bug for the L3 to be pinned but not all the which L1s which it contains.
> Can you try this patch which tries to notice this situation and prints
> some potentially interesting information, similarly on the fault it
> dumps a little more info. Since I can't repro I've only tested that it
> doesn't break normal use, I've not actually seen the debug trigger...
> 

OK. I'll try later today.. 

> 
> 
> I'd guess that this would at least work around the issue, I doubt it's a
> proper fix and it's going to shaft perf I suspect (not that highpte
> won't be doing a pretty good job of that ;-)).
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index fefdeee..4c694e4 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1521,7 +1521,7 @@ static void *xen_kmap_atomic_pte(struct page *page, 
> enum km_type type)
>  {
>       pgprot_t prot = PAGE_KERNEL;
>  
> -     if (PagePinned(page))
> +     if (1 || PagePinned(page))
>               prot = PAGE_KERNEL_RO;
>  
>       if (0 && PageHighMem(page))
> 

I'll try just the first debug-patch first.. so I won't apply this one yet.

-- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel