[PATCH v3 2/4] powerpc: Fixes for CONFIG_PTE_64BIT for SMP support

Kumar Gala galak at kernel.crashing.org
Sun Sep 7 01:32:46 EST 2008


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



More information about the Linuxppc-dev mailing list