* Erroneous VM_MINOR_FAULT return from filemap_fault?
@ 2008-01-03 20:24 Steven Walter
0 siblings, 0 replies; only message in thread
From: Steven Walter @ 2008-01-03 20:24 UTC (permalink / raw)
To: linux-mm
There appears to be a path through filemap_fault such that the function
returns VM_MINOR_FAULT, even though disk IO was performed. Suppose that
the page in question is not already in the page cache (find_lock_page
returns NULL) and we trip the MMAP_LOTSAMISS logic, ending up at
no_cached_page. Immediately page_cache_read is called, but ret was
never set to VM_MAJOR_FAULT (still at the default of VM_MINOR_FAULT).
Control jumps back to retry_find, find_lock_page returns the page, and
eventually the function returns VM_MINOR_FAULT.
Is there some assumption I'm missing where the execution path I
summarized couldn't actually happen? Perhaps this behavior is
intentional? Certainly it seems that if IO is performed, the fault
should be considered a major fault.
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
--
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:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2008-01-03 20:24 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-03 20:24 Erroneous VM_MINOR_FAULT return from filemap_fault? Steven Walter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox