Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [PATCH] block: replace __getblk_slow misfix by grow_dev_page fix | Date | Thu, 23 Aug 2012 16:40:11 -0400 |
| |
Hugh Dickins <hughd@google.com> writes:
> [PATCH] block: replace __getblk_slow misfix by grow_dev_page fix > > Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow") > is not good: a successful call to grow_buffers() cannot guarantee > that the page won't be reclaimed before the immediate next call to > __find_get_block(), which is why there was always a loop there. [snip] > Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus > a checkpatch nitfix). Simplify the interface between grow_buffers() > and grow_dev_page(), and avoid the infinite loop beyond end of device > by instead checking init_page_buffers()'s end_block there (I presume > that's more efficient than a repeated call to blkdev_max_block()), > returning -ENXIO to __getblk_slow() in that case. > > And remove akpm's ten-year-old "__getblk() cannot fail ... weird" > comment, but that is worrying: are all users of __getblk() really > now prepared for a NULL bh beyond end of device, or will some oops??
Hi, Hugh,
Thanks for digging into this. I had wondered whether that loop was required for other purposes, and you've verified that it was. I mostly like your fix. Returning end_block from init_page_buffers is a little strange, but I understand not wanting to redo the call to blkdev_max_block.
I went ahead to re-tested with the reproducer that I had, and your patch works fine. Thanks again for tracking this down, and sorry I wasn't more diligent to begin with.
Reviewed-and-Tested-by: Jeff Moyer <jmoyer@redhat.com>
| |