All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Josef Bacik <jbacik@fusionio.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: don't BUG_ON() in btrfs_num_copies
Date: Wed, 24 Apr 2013 16:45:47 +0200	[thread overview]
Message-ID: <20130424144547.GD16427@twin.jikos.cz> (raw)
In-Reply-To: <1366728893-1529-1-git-send-email-jbacik@fusionio.com>

On Tue, Apr 23, 2013 at 10:54:53AM -0400, Josef Bacik wrote:
> A user sent me a btrfs-image that was panicing because of some corruption.  This
> is because we pass in a bogus value to btrfs_num_copies, and it panics.  Instead
> just return 1.  We only call btrfs_num_copies to see if there are other copies
> to try and read for things, so if we just return 1 it will make the callers exit
> out with an appropriate error value.  Thanks,
> 
> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> ---
>  fs/btrfs/volumes.c |   20 ++++++++++++++++++--
>  1 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index c8a315d..c1a2217 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -4232,9 +4232,25 @@ int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 logical, u64 len)
>  	read_lock(&em_tree->lock);
>  	em = lookup_extent_mapping(em_tree, logical, len);
>  	read_unlock(&em_tree->lock);
> -	BUG_ON(!em);
>  
> -	BUG_ON(em->start > logical || em->start + em->len < logical);
> +	/*
> +	 * We could return errors for these cases, but that could get ugly and
> +	 * we'd probably do the same thing which is just not do anything else
> +	 * and exit, so return 1 so the callers don't try to use other copies.
> +	 */

This is safe on all the repair paths, they bail out if there's only one
copy. In the integrity checker btrfs_num_copies value is used to process
all copies, btrfs(ic)_map_block is called afterwards and bails out
eventually. Both functions fail on the same call to
lookup_extent_mapping(), so it adds only some minor extra work but we're
interested if it's safe to return 1, I think it is.


> +	if (!em) {
> +		btrfs_emerg(fs_info, "No mapping for %Lu-%Lu\n", logical,
> +			    logical+len);

				(unsigned long long)logical,
				(unsigned long long)(logical + len)

> +		return 1;
> +	}
> +
> +	if (em->start > logical || em->start + em->len < logical) {
> +		btrfs_emerg(fs_info, "Invalid mapping for %Lu-%Lu, got "
> +			    "%Lu-%Lu\n", logical, logical+len, em->start,
> +			    em->start + em->len);

dtto

> +		return 1;
> +	}
> +
>  	map = (struct map_lookup *)em->bdev;
>  	if (map->type & (BTRFS_BLOCK_GROUP_DUP | BTRFS_BLOCK_GROUP_RAID1))
>  		ret = map->num_stripes;

Reviewed-by: David Sterba <dsterba@suse.cz>

      reply	other threads:[~2013-04-24 14:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-23 14:54 [PATCH] Btrfs: don't BUG_ON() in btrfs_num_copies Josef Bacik
2013-04-24 14:45 ` David Sterba [this message]

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=20130424144547.GD16427@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.