On Wed, 20 Feb 2002, Daniel Phillips wrote:
> On February 19, 2002 07:11 pm, Hugh Dickins wrote:
> >
> > It's a little worse than this, I think. Propagating pte_dirty(pte) to
> > set_page_dirty(page) cannot be done until after the flush_tlb_cpus,
>
> You mean, because somebody might re-dirty an already cleaned page? Or are
> you driving at something more subtle?
You are right to press me on this. Now I reflect upon it, I think I
was scare-mongering, and I'm sure you don't need that! I apologize.
If the i386 pte was already marked dirty, there's no issue at all.
If the i386 pte was not already marked dirty, but another processor
has that entry in its TLB (not marked dirty), and goes to dirty it
at the wrong moment, either it does so successfully just before the
ptep_get_and_clear (and we see the dirty bit), or it tries to do so
just after the (atomic part of) the ptep_get_and_clear, finds pte
not present and faults (page not yet dirtied). No problem.
This (one cpu invalidating pte while another is halfway through ucode
updating dirty or referenced bit) is errata territory on Pentium Pro.
But if we were going to worry about that, we should have done so
before, you're not introducing any new problem in that respect.
I'm unfamiliar with the other architectures, but I have no reason
to suppose they behave critically differently here. Ben will have
checked this all out when he brought in tlb_remove_page(): and though
his propagation of dirty from pte to page occurs after the flush TLB,
it's irrelevant: that pte comes from ptep_get_and_clear before.
Sorry again,
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:25 EST