[PATCH] __getblk_slow can loop forever when pages are partially mapped
When a block device is accessed via read/write, it is possible for some of the buffers on a page to be mapped and others not. __getblk and friends assume this can't happen, and can end up looping forever when pages have some unmapped buffers. Picture: lseek(/dev/xxx, 2048, SEEK_SET) write(/dev/xxx, 2048 bytes) Assuming the block size is 1k, page 0 has 4 buffers, two are mapped by __block_prepare_write and two are not. Next, another process triggers getblk(/dev/xxx, blocknr = 0); __getblk_slow will loop forever. __find_get_block fails because the buffer isn't mapped. grow_dev_page does nothing because there are buffers on the page with the correct size. madhav@veritas.com and others at Veritas tracked this down. The fix below has two parts. First, it changes __find_get_block to avoid the buffer_error warnings when it finds unmapped buffers on the page. Second, it changes grow_dev_page to map the buffers on the page by calling init_page_buffers. init_page_buffers is changed so we don't stomp on uptodate bits for the buffers. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment