[lkml]   [2003]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2.5.66-mm2] Fix page_convert_anon locking issues
On Thu, 3 Apr 2003, Dave McCracken wrote:
> I thought of a big hole in the simpler scheme you suggested. It occurred
> to me that try_to_unmap will fail. It will see the PageAnon flag so it'll
> just walk the pte_chain and assume it doesn't have to walk the vmas. This
> will leave the page with some stranded mappings. Actually
> page_convert_anon will then finish, and we'll have a page where
> try_to_unmap claims it has succeeded but still has mappings.

I don't see that as a big hole at all. While we're in page_convert_anon,
yes, page_referenced won't find all the ptes and try_to_unmap won't be
able to unmap them all; but there are plenty of other reasons why a page
may be briefly unfreeable even though try_to_unmap succeeded, it'll just
try again later.

I haven't really had my think yet, but the only difficulty I've seen so
far is in maintaining the nr_mapped stats correctly. page_convert_anon
insert an initial dummy entry (the entry install_page is about to add?)
to make sure page_mapped cannot go false?

(Hmm, is the current page_convert_anon maintaining nr_reverse_maps
correctly? I would think not, since it's doing nothing about it, and
page_remove_rmap would decrement seeing an Anon. But perhaps I'm
confused again, a quick test doesn't show the drop I'd expect.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.067 / U:1.616 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site