hash table

[Olof Johansson]

Benjamin Herrenschmidt wrote:

>I think there is no race with the flush code. The reason is that
>the case where flush is called on a present page seem to be strictly
>limited to a PP bits update (or an accessed bits update in some
>error case, but we can dismiss that one completely I beleive).
>
>
>Since flush uses pte_update, it will not race with a pending
>_hash_page. The only possible race is a __hash_page occuring during
>a flush. But in this case, the PTE will have the new PP bits already
>so at worst, we exit flush with an entry present... but that has the
>new bits. So it's ok. I don't think we can race on the content of
>the HPTE neither as we have the HPTE lock bit there. I'd still
>like your point of view though.
>
>
I can see a race between the find_linux_pte() and the use of ptep in
__hash_page. Another CPU can come in during that window and deallocate
the PTE, can't it? One solution for this is to set _PAGE_BUSY in
find_linux_pte() atomically during lookup. There's even more subtle
races in the sense that the tree is walked while someone might update it
underneath of the lookup, but maybe they can be ignored?

Also two minor comments:

* in pte_update, use _PAGE_BUSY instead of hardcoded 0x0800? Would
increase readability a little.

* in __hash_page / htab_wrong_access: There's no check for failed stdcx.


-Olof


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/