Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow")is not good: a successful call to grow_buffers() cannot guaranteethat the page won't be reclaimed before the immediate next call to__find_get_block(), which is why there was always a loop there.

I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfssometimes fails from a missing header file, under memory pressure onppc G5. I've never seen this on x86, and I've never seen it on 3.5-rc7itself, despite that commit being in there: bisection pointed to anirrelevant pinctrl merge, but hard to tell when failure takes between18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).

(I've since found such __ext4_get_inode_loc errors in /var/log/messagesfrom previous weeks: why the message never appeared on console untilyesterday morning is a mystery for another day.)

Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plusa checkpatch nitfix). Simplify the interface between grow_buffers()and grow_dev_page(), and avoid the infinite loop beyond end of deviceby instead checking init_page_buffers()'s end_block there (I presumethat'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() reallynow prepared for a NULL bh beyond end of device, or will some oops??