All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Fwd: Re: [PATCH] btrfs: add more superblock checks
Date: Tue, 7 Oct 2014 16:51:11 +0800	[thread overview]
Message-ID: <5433A97F.8050509@cn.fujitsu.com> (raw)
In-Reply-To: <5433A7D7.4080401@cn.fujitsu.com>

Previous reply seems failed to be delivered.

Resend.

-------- 转发的消息 --------
主题: 	Re: [PATCH] btrfs: add more superblock checks
日期: 	Tue, 07 Oct 2014 16:44:07 +0800
发件人: 	Qu Wenruo <quwenruo@cn.fujitsu.com>
收件人: 	David Sterba <dsterba@suse.cz>, linux-btrfs@vger.kernel.org



Thanks a lot for the patch to deal with the broken image.

Also this seems more extendable.

Small comment inlined below.

-------- Original Message --------
Subject: [PATCH] btrfs: add more superblock checks
From: David Sterba <dsterba@suse.cz>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年10月01日 01:16
> Populate btrfs_check_super_valid() with checks that try to verify
> consistency of superblock by additional conditions that may arise from
> corrupted devices or bitflips. Some of tests are only hints and issue
> warnings instead of failing the mount, basically when the checks are
> derived from the data found in the superblock.
>
> Tested on a broken image provided by Qu.
>
> Reported-by: Qu Wenruo<quwenruo@cn.fujitsu.com>
> Signed-off-by: David Sterba<dsterba@suse.cz>
> ---
>   fs/btrfs/disk-io.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
>   1 file changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index a1d36e62179c..bfb00cb1c84c 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -3814,10 +3814,73 @@ int btrfs_read_buffer(struct extent_buffer *buf, u64 parent_transid)
>   static int btrfs_check_super_valid(struct btrfs_fs_info *fs_info,
>   			      int read_only)
>   {
> +	struct btrfs_super_block *sb = fs_info->super_copy;
> +	int ret = 0;
> +
> +	if (sb->root_level > BTRFS_MAX_LEVEL) {
> +		printk(KERN_ERR "BTRFS: tree_root level too big: %d > %d\n",
> +				sb->root_level, BTRFS_MAX_LEVEL);
> +		ret = -EINVAL;
> +	}
> +	if (sb->chunk_root_level > BTRFS_MAX_LEVEL) {
> +		printk(KERN_ERR "BTRFS: chunk_root level too big: %d > %d\n",
> +				sb->chunk_root_level, BTRFS_MAX_LEVEL);
> +		ret = -EINVAL;
> +	}
> +	if (sb->log_root_level > BTRFS_MAX_LEVEL) {
> +		printk(KERN_ERR "BTRFS: log_root level too big: %d > %d\n",
> +				sb->log_root_level, BTRFS_MAX_LEVEL);
> +		ret = -EINVAL;
> +	}
> +
>   	/*
> -	 * Placeholder for checks
> +	 * The common minimum, we don't know if we can trust the nodesize/sectorsize
> +	 * items yet, they'll be verified later. Issue just a warning.
>   	 */
> -	return 0;
> +	if (!IS_ALIGNED(sb->root, 4096))
> +		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
> +				sb->root);
> +	if (!IS_ALIGNED(sb->chunk_root, 4096))
> +		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
> +				sb->chunk_root);
> +	if (!IS_ALIGNED(sb->log_root, 4096))
> +		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
> +				sb->log_root);
1) it is better not to call IS_ALIGNED to immediate value//.
Although current btrfs implement ensures that all sectorsize is larger 
equal than page_size,
but Chandan Rajendra is trying to support subpage-sized blocksize,
which may cause false alert later.

It would be much better using btrfs_super_sectorsize() instead to 
improve extendability.

2) missing endian convert.
On big endian system it would be a disaster....
btrfs_super_* marco should be used.

> +
> +	if (memcmp(fs_info->fsid, sb->dev_item.fsid, BTRFS_UUID_SIZE) != 0) {
> +		printk(KERN_ERR "BTRFS: dev_item UUID does not match fsid: %pU != %pU\n",
> +				fs_info->fsid, sb->dev_item.fsid);
> +		ret = -EINVAL;
> +	}
> +
> +	/*
> +	 * Hint to catch really bogus numbers, bitflips or so, more exact checks are
> +	 * done later
> +	 */
> +	if (sb->num_devices > (1UL << 31))
> +		printk(KERN_WARNING "BTRFS: suspicious number of devices: %llu\n",
> +				sb->num_devices);
What about also check the devid with sb->num_devices too?
Every valid devid should be less equal than sb->num_devices if I am right.
Although iterate dev_item here may be overkilled...
> +
> +	if (sb->bytenr != BTRFS_SUPER_INFO_OFFSET) {
> +		printk(KERN_ERR "BTRFS: super offset mismatch %llu != %u\n",
> +				sb->bytenr, BTRFS_SUPER_INFO_OFFSET);
> +		ret = -EINVAL;
> +	}
> +
> +	/*
> +	 * The generation is a global counter, we'll trust it more than the others
> +	 * but it's still possible that it's the one that's wrong.
> +	 */
> +	if (sb->generation < sb->chunk_root_generation)
> +		printk(KERN_WARNING
> +			"BTRFS: suspicious: generation < chunk_root_generation: %llu < %llu\n",
> +			sb->generation, sb->chunk_root_generation);
> +	if (sb->generation < sb->cache_generation && sb->cache_generation != (u64)-1)
> +		printk(KERN_WARNING
> +			"BTRFS: suspicious: generation < cache_generation: %llu < %llu\n",
> +			sb->generation, sb->cache_generation);
> +
> +	return ret;
>   }
>   
Still the endian problem.

Thanks,
Qu
>   static void btrfs_error_commit_super(struct btrfs_root *root)




       reply	other threads:[~2014-10-07  8:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5433A7D7.4080401@cn.fujitsu.com>
2014-10-07  8:51 ` Qu Wenruo [this message]
2014-10-09 15:43   ` Fwd: Re: [PATCH] btrfs: add more superblock checks David Sterba

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=5433A97F.8050509@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.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.