Thread (47 messages) 47 messages, 7 authors, 2003-05-17

Re: Race between vmtruncate and mapped areas?

From: Andrew Morton <hidden>
Date: 2003-05-14 18:40:59
Also in: lkml

Dave McCracken [off-list ref] wrote:

--On Wednesday, May 14, 2003 11:17:48 -0700 Andrew Morton [off-list ref]
wrote:
quoted
I think it might be sufficient to re-check the page against i_size
after IO completion in filemap_nopage().
It would definitely make the window a lot smaller, though it won't quite
close it.  To be entirely safe we'd need to recheck after we've retaken
page_table_lock.
hmm.

One possible timing diagram is



	truncate:				pagefault:


						check i_size

						grab page
	drop i_size

	shoot down pagetables

						install in pagetables

	truncate file


converting i_sem to an rwsem and taking it in the pagefault would certainly
stitch it up.  Unpopular, very messy.

Could "truncate file" return some code to say pages were left behind, so
truncate re-runs zap_page_range()?  Sounds unpleasant.


Yes, re-checking the page against i_size from do_no_page() would fix it up.
 But damn, that's another indirect call, 64-bit math, etc on _every_
file-backed pagefault.


Remind me again what problem this whole thing is currently causing?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help