All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Bob Copeland <me@bobcopeland.com>
Cc: linux-kernel@vger.kernel.org, snakebyte@gmx.de
Subject: Re: __getblk infinite loop
Date: Thu, 4 Sep 2008 22:38:36 -0700	[thread overview]
Message-ID: <20080904223836.54fbabb1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080905032411.GB13208@hash.localnet>

On Thu, 4 Sep 2008 23:24:11 -0400 Bob Copeland <me@bobcopeland.com> wrote:

> Hi all,
> 
> Eric Sesterhenn and I were puzzling over a lockup found by his fsfuzzer.
> 
> sb_bread() calls __getblk, which says:
> 
> /*
>  * __getblk will locate (and, if necessary, create) the buffer_head
>  * which corresponds to the passed block_device, block and size. The
>  * returned buffer has its reference count incremented.
>  *
>  * __getblk() cannot fail - it just keeps trying.  If you pass it an
>  * illegal block number, __getblk() will happily return a buffer_head
>  * which represents the non-existent block.  Very weird.
>  *
>  * __getblk() will lock up the machine if grow_dev_page's try_to_free_buffers()
>  * attempt is failing.  FIXME, perhaps?
>  */
> 
> In fact the following will cause an infinite loop when mounting omfs 
> loopback (on 32 bit x86 at least):
> 
> diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
> index a95fe59..80eacc8 100644
> --- a/fs/omfs/inode.c
> +++ b/fs/omfs/inode.c
> @@ -413,6 +413,15 @@ static int omfs_fill_super(struct super_block *sb, void *data, int silent)
>  	sector_t start;
>  	int ret = -EINVAL;
>  
> +	if (1) {
> +		sector_t foo = 0x1d4000004ULL;
> +
> +		sb_set_blocksize(sb, 2048);
> +		bh = sb_bread(sb, foo);
> +		brelse(bh);
> +		goto end;
> +	}
> +
>  	save_mount_options(sb, (char *) data);
>  
>  	sbi = kzalloc(sizeof(struct omfs_sb_info), GFP_KERNEL);
> 
> What's supposed to happen here?  I would have thought that sb_bread
> would realize foo was outside the block dev and bail out, but instead
> it just gets stuck.  Do I need to bounds-check anything passed to
> sb_bread?

That loop does lock up on people occasionally - last time was in isofs,
because it had done an insane set_blocksize() earlier on.

Yes, it's always a case of garbage in, garbage out (or nothing out, as
the case may be).

No, it's not particularly programmer-friendly behaviour.


  reply	other threads:[~2008-09-05  5:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-05  3:24 __getblk infinite loop Bob Copeland
2008-09-05  5:38 ` Andrew Morton [this message]
2008-09-05  9:20   ` Eric Sesterhenn
2008-09-10 12:33     ` Bob Copeland
2008-09-05 14:58   ` Bob Copeland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080904223836.54fbabb1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@bobcopeland.com \
    --cc=snakebyte@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.