Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}

[Hugh Dickins]

On Mon, 26 Mar 2007, Zachary Amsden wrote:
> David Rientjes wrote:
> >  Date: Sun, 25 Mar 2007 23:07:43 -0800
> >  From: Zachary Amsden <zach@xxxxxxxxxx>
> >
> >  If you actually clear the bit, you need to:
> >
> >  +         pte_update_defer(vma->vm_mm, addr, ptep);
> >
> >  The reason is, when updating PTEs, the hypervisor must be notified.  Using
> >  atomic operations to do this is fine for all hypervisors I am aware of.
> >  However, for hypervisors which shadow page tables, if these PTE
> >  modifications are not trapped, you need a post-modification call to fulfill
> >  the update of the shadow page table.
> >
> > Cc: Zachary Amsden <zach@xxxxxxxxxx>
> > Cc: Hugh Dickins <hugh@xxxxxxxxxxx>
> > Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx>
> >   
> 
> Acked-by: Zachary Amsden <zach@xxxxxxxxxx>
> 
> David, thanks for cleaning this up.

Zach, while looking at your recent patches, I ran across the comment
on pte_update_defer, and where it was being used, and now think that
David's patch is actually incorrect.  Previously pte_update_defer
was being used where a flush_tlb_page followed immediately after
within the same macro; with David's patch, mm's clear_refs_pte_range
is calling ptep_test_and_clear_young (including pte_update_defer) on
several ptes, then unlocking the page table, and later flushing TLB.
That's exactly wrong for pte_update_defer, isn't it?

I do find the name confusing (pte_update_defer is for use only when
the TLB update is not deferred, right?): indeed, its distinction from
pte_update very prone to errors of this kind.  I'm all for deferring
work, but is there some way the right thing could be done automatically?
Or, how much would be lost if we just replaced all the pte_update_defers
by pte_updates?

I'm not proposing any patch myself: just bringing to your attention.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/