There exists an inconsistency in calculation of page cache index between __find_get_block_slow and grow_buffers. __bread(bdev, 64, 1024); With 4k page size and block size, above usage causes infinite loop in __getblk_slow. This is not to say it doesn't have issues with different page size or block size. __find_get_block (in __find_get_block_slow) tries to find buffers associated with page indexed at "block >> (PAGE_SHIFT - bd_inode->i_blkbits);", i.e. index 64. grow_buffers calculates the page index in a different way which gives 16 for the page index number, thus eventually associates the 4 newly created buffers (4K page equally divided into 4 buffers of 1024 bytes) with the page at index 16. So __find_get_block will never find the newly created buffer and stuck in the loop. Using i_blkbits for the calculation in grow_buffers seems to work, but there are more concerns. For example, end_block and b_blocknr calculation in init_page_buffers assumes block size equals to buffer size, and a similar situation in submit_bh_wbc while calculating bi_sector. I made some minor changes to these places to use block size instead of b_size, which looks ok with a few simple test cases. I would really appreciate if someone could give more insight on the issue and potential impact on the changes of page cache index and b_blocknr calculation before I go ahead spent more time on it. Thanks, Liang
