invalidate_complete_page()
This is buggy, isn't it? If someone faults the page into pagetables after invalidate_mapping_pages() checked page_mapped(), the faulter-inner gets an anonymous, not-up-to-date page which he didn't expect.
Locking the page in the pagefault handler will fix that, but meanwhile I think we need to be checking page_count() in invalidate_complete_page(), after taking tree_lock?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 4 lines · Andrew Morton
This is buggy, isn't it? If someone faults the page into pagetables after
invalidate_mapping_pages()checkedpage_mapped(), the faulter-inner gets an anonymous, not-up-to-date page which he didn't expect.
You're right. ("anonymous" meaning "detached" rather than PageAnon.)
Quoted 2 lines
Locking the page in the pagefault handler will fix that,
(I thought I scared you off that? Just for a while perhaps. If Nick plugs the hole(s?) he noticed in his earlier patch, and wider performance testing shows that the hit is acceptable, then we'd all agree it's the best way to go.)
Quoted 3 lines
but meanwhile I
think we need to be checkingpage_count()ininvalidate_complete_page(), after takingtree_lock?
Yes, that should do nicely: it's already happy to skip on lots of transient circumstances, no harm in adding another such, to avoid the more serious inconsistency you notice above.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>