[PATCH] mpage_writepages() i_size reading fix
I believe reading the i_size from memory multiple times can generate fs corruption. The "offset" and the "end_index" were not coherent. this is writepages and it runs w/o the i_sem, so the i_size can change from under us anytime. If a parallel write happens while writepages run, the i_size could advance from 4095 to 4100. With the current 2.6 code that could translate in end_index = 0 and offset = 4. That's broken because end_index and offset could be not coherent. Either end_index=1 and offset =4, or end_index = 0 and offset = 4095. When they lose coherency the memset can zeroout actual data. The below patch fixes that (it's at least a theoretical bug). I don't really expect this tiny race to fix the bug in practice after the more serious bugs we covered yesterday didn't fix it (more likely the compiler will get involved into the equation soon ;). This is also an optimization for 32bit archs that needs special locking to read 64bit i_size coherenty. This patch also arranges for mpage_writepages() to always zero out the file's final page between i_size and the end of the file's final block. This is a best-effort correctness thing to deal with errant applications which write into the mmapped page beyond the underlying file's EOF. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment