Re: [RFC][PATCH] EXT3: problem with page fault inside a transaction
Nick Piggin <[email protected]> Thu, 12 Oct 2006 18:31:23 +1000
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm,gmane.comp.file-systems.ext2.devel |
|---|---|
| Message-ID | <[email protected]> |
Dmitriy Monakhov wrote: > Andrew Morton <[email protected]> writes: >>With the stuff Nick and I are looking at, we won't take pagefaults inside >>prepare_write()/commit_write() any more. > > I'sorry may be i've missed something, but how cant you prevent this? > > Let's look at generic_file_buffered_write: > #### force page fault > fault_in_pages_readable(); > > ### find and lock page > __grab_cache_page() > > #### allocate blocks.This may result in low memory condition > #### try_to_free_pages->shrink_caches() and etc. > a_ops->prepare_write() > > ### can anyone guarantee that page fault hasn't happened by now ? Yes. Do an atomic copy, which will early exit from the pagefault handler and return a short copy. Then close up the write, drop the page lock, and rerun the fault_in_pages_readable, which will do the full pagefaults for us, then try again. Regardless of what you do to ext3, the VM just can't handle a fault here anyway. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com