Messages in this thread | | | Date | Wed, 2 Apr 2003 15:38:45 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 2.5.66-mm2] Fix page_convert_anon locking issues |
| |
Dave McCracken <dmccr@us.ibm.com> wrote: > > > 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.
But:
+ /* Double check to make sure the pte page hasn't been freed */ + if (!pmd_present(*pmd)) + goto out_unmap; + ==> munmap, pte page is freed, reallocated for pagecache, someone happens to write the correct value into it. + if (page_to_pfn(page) != pte_pfn(*pte)) + goto out_unmap; + + if (addr) + *addr = address; +
> >> 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.
OK, I'll edit the diffs at a convenient time.
> >> 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.
That debug already triggers if it is enabled. I forget why, but it's OK.
> Lemme > think on this one a bit. I need to assure myself it's safe to go unlocked > in the middle.
Thanks. It's tricky. I wish we had more tests for this stuff, and real applications which use it...
- 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/
| |