On Sep 5, 2008, at 5:38 PM, Benjamin Herrenschmidt wrote:
On Fri, 2008-09-05 at 14:44 -0500, Kumar Gala wrote:
I also wonder if you should first ensure that the PTE is invalid and
if not, clear it and flush the TLB page ... Or at least add a
WARN_ON(pte_valid()) in case we get that wrong ...
I believe that's an issue since kmap_atomic() will call set_pte_at
and
have the valid bit set.
Hrm... on the other hand, it's safe because kmap_atomic() is per-CPU
and
thus won't race with anything...
On the other hand, if others (mprotect, mremap, whoever...) does it,
it's not safe.
I'm keen on letting set_pte_at() to the job and maybe if we can remove
the explicit flush kmap_atomic does... Though it's not totally trivial
to "know" it's a flush that doesn't need global invalidations...
May be worth moving your current stuff into a __set_pte_at() that you
use from kmap atomic, and have set_pte_at() wrap that along with a
present warn. That would do for the time being.
That works for me.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
