Re: [patch] block: fix infinite loop in __getblk_slow

[Josh Boyer]

On Tue, Jun 26, 2012 at 10:55 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote:
> Hi,
>
> This commit:
>
> commit 080399aaaf3531f5b8761ec0ac30ff98891e8686
> Author: Jeff Moyer <jmoyer@xxxxxxxxxx>
> Date:   Fri May 11 16:34:10 2012 +0200
>
>     block: don't mark buffers beyond end of disk as mapped
>
> exposed a bug in __getblk_slow that causes mount to hang as it loops
> infinitely waiting for a buffer that lies beyond the end of the disk to
> become uptodate.  The problem was initially reported by Torsten Hilbrich
> here: https://lkml.org/lkml/2012/6/18/54, and also reported
> independently here:
> http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511, and then
> Richard W.M. Jones and Marcos Mello noted a few separate bugzillas also
> associated with the same issue.
>
> The main problem is here, in __getblk_slow:
>
>         for (;;) {
>                 struct buffer_head * bh;
>                 int ret;
>
>                 bh = __find_get_block(bdev, block, size);
>                 if (bh)
>                         return bh;
>
>                 ret = grow_buffers(bdev, block, size);
>                 if (ret < 0)
>                         return NULL;
>                 if (ret == 0)
>                         free_more_memory();
>         }
>
> __find_get_block does not find the block, since it will not be marked as
> mapped, and so grow_buffers is called to fill in the buffers for the
> associated page.  I believe the for (;;) loop is there primarily to
> retry in the case of memory pressure keeping grow_buffers from
> succeeding.  However, we also continue to loop for other cases, like the
> block lying beond the end of the disk.  So, the fix I came up with is to
> only loop when grow_buffers fails due to memory allocation issues
> (return value of 0).
>
> The attached patch was tested by myself, Torsten, and Rich, and was
> found to resolve the problem in call cases.
>
> Comments, as always, are appreciated.

Is this needed in addition to your earlier patch here:

http://article.gmane.org/gmane.linux.kernel/1316228

or is it a replacement for that?

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/