> i_shared_sem won't stop that. The pte points into thin air, and may now
> point at a value which looks like our page.
Once we find a match in the pte entry, we have the additional protection of
the pte_chain lock. The pte entry is never cleared without a call to
page_remove_rmap, which will block on the pte_chain lock.
>> Because the page is in transition from !PageAnon to PageAnon.
> These are file-backed pages. So what does PageAnon really mean?
I suppose PageAnon should be renamed to PageChain, to mean it's using
pte_chains. It did mean anon pages until I used it for nonlinear pages.
>> We have to
>> hold the pte_chain lock during the entire transition in case someone else
>> tries to do something like page_remove_rmap, which would break.
> How about setting PageAnon at the _start_ of the operation?
> page_remove_rmap() will cope with that OK.
Hmm... I was gonna say that page_remove_rmap will BUG() if it doesn't find
the entry, but it's only under DEBUG and could easily be changed. Lemme
think on this one a bit. I need to assure myself it's safe to go unlocked
in the middle.
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
email@example.com T/L 678-3059
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/