Re: [PATCH 2.5.66-mm2] Fix page_convert_anon locking issues

Andrew Morton (akpm@digeo.com)
Wed, 2 Apr 2003 15:38:45 -0800


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/