Messages in this thread | | | From | Herbert Xu <> | Subject | Re: Possible memory ordering bug in page reclaim? | Date | Sat, 15 Oct 2005 18:00:24 +1000 |
| |
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > >> > 1 2 >> > find_get_page(); >> > write to page write_lock(tree_lock); >> > SetPageDirty(); if (page_count != 2 >> > put_page(); || PageDirty()) >> > >> > Now I'm worried that 2 might see PageDirty *before* SetPageDirty in >> page->flags >> > 1, and page_count *after* put_page in 1. > > yup, now the question is wether PG_Dirty will be visible to CPU 2 before > the page count is decremented right ? That depends on put_page, I > suppose. If it's doing a simple atomic, there is an issue. But atomics > with return has been so often abused as locks that they may have been > implemented with a barrier... (On ppc64, it will do an eieio, thus I > think it should be ok).
Yes atomic_add_negative should always be a barrier.
> There is also a problem the other way around. Write to page, then set > page dirty... those writes may be visible to CPU 2 (that is the page > content be dirty) before find_get_page even increased the page count, > unless there is a barrier in there too.
find_get_page does a read_unlock_irq after the increment which also serves as a barrier.
Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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/
| |