* [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56
2017-03-30 6:32 [PATCH v4 0/5] raid56: scrub related fixes Qu Wenruo
@ 2017-03-30 6:32 ` Qu Wenruo
2017-03-30 16:49 ` Liu Bo
2017-03-30 6:32 ` [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition Qu Wenruo
` (3 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2017-03-30 6:32 UTC (permalink / raw)
To: linux-btrfs; +Cc: bo.li.liu
Unlike mirror based profiles, RAID5/6 recovery needs to read out the
whole full stripe.
And if we don't do proper protect, it can easily cause race condition.
Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
for RAID5/6.
Which stores a rb_tree of mutex for full stripes, so scrub callers can
use them to lock a full stripe to avoid race.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
---
fs/btrfs/ctree.h | 17 ++++
fs/btrfs/extent-tree.c | 11 +++
fs/btrfs/scrub.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 245 insertions(+)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 29b7fc28c607..9fe56da21fed 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -538,6 +538,14 @@ struct btrfs_io_ctl {
unsigned check_crcs:1;
};
+/*
+ * Tree to record all locked full stripes of a RAID5/6 block group
+ */
+struct btrfs_full_stripe_locks_tree {
+ struct rb_root root;
+ struct mutex lock;
+};
+
struct btrfs_block_group_cache {
struct btrfs_key key;
struct btrfs_block_group_item item;
@@ -648,6 +656,9 @@ struct btrfs_block_group_cache {
* Protected by free_space_lock.
*/
int needs_free_space;
+
+ /* Record locked full stripes for RAID5/6 block group */
+ struct btrfs_full_stripe_locks_tree full_stripe_locks_root;
};
/* delayed seq elem */
@@ -3647,6 +3658,12 @@ int btrfs_scrub_cancel_dev(struct btrfs_fs_info *info,
struct btrfs_device *dev);
int btrfs_scrub_progress(struct btrfs_fs_info *fs_info, u64 devid,
struct btrfs_scrub_progress *progress);
+static inline void btrfs_init_full_stripe_locks_tree(
+ struct btrfs_full_stripe_locks_tree *locks_root)
+{
+ locks_root->root = RB_ROOT;
+ mutex_init(&locks_root->lock);
+}
/* dev-replace.c */
void btrfs_bio_counter_inc_blocked(struct btrfs_fs_info *fs_info);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index be5477676cc8..5f51ce81f484 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -131,6 +131,16 @@ void btrfs_put_block_group(struct btrfs_block_group_cache *cache)
if (atomic_dec_and_test(&cache->count)) {
WARN_ON(cache->pinned > 0);
WARN_ON(cache->reserved > 0);
+
+ /*
+ * If not empty, someone is still holding mutex of
+ * full_stripe_lock, which can only be released by caller.
+ * And it will definitely cause use-after-free when caller
+ * tries to release full stripe lock.
+ *
+ * No better way to resolve, but only to warn.
+ */
+ WARN_ON(!RB_EMPTY_ROOT(&cache->full_stripe_locks_root.root));
kfree(cache->free_space_ctl);
kfree(cache);
}
@@ -9917,6 +9927,7 @@ btrfs_create_block_group_cache(struct btrfs_fs_info *fs_info,
btrfs_init_free_space_ctl(cache);
atomic_set(&cache->trimming, 0);
mutex_init(&cache->free_space_lock);
+ btrfs_init_full_stripe_locks_tree(&cache->full_stripe_locks_root);
return cache;
}
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index b0251eb1239f..5fc99a92b4ff 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -240,6 +240,13 @@ struct scrub_warning {
struct btrfs_device *dev;
};
+struct full_stripe_lock {
+ struct rb_node node;
+ u64 logical;
+ u64 refs;
+ struct mutex mutex;
+};
+
static void scrub_pending_bio_inc(struct scrub_ctx *sctx);
static void scrub_pending_bio_dec(struct scrub_ctx *sctx);
static void scrub_pending_trans_workers_inc(struct scrub_ctx *sctx);
@@ -349,6 +356,216 @@ static void scrub_blocked_if_needed(struct btrfs_fs_info *fs_info)
}
/*
+ * Insert new full stripe lock into full stripe locks tree
+ *
+ * Return pointer to existing or newly inserted full_stripe_lock structure if
+ * everything works well.
+ * Return ERR_PTR(-ENOMEM) if we failed to allocate memory
+ *
+ * NOTE: caller must hold full_stripe_locks_root->lock before calling this
+ * function
+ */
+static struct full_stripe_lock *insert_full_stripe_lock(
+ struct btrfs_full_stripe_locks_tree *locks_root,
+ u64 fstripe_logical)
+{
+ struct rb_node **p;
+ struct rb_node *parent = NULL;
+ struct full_stripe_lock *entry;
+ struct full_stripe_lock *ret;
+
+ WARN_ON(!mutex_is_locked(&locks_root->lock));
+
+ p = &locks_root->root.rb_node;
+ while (*p) {
+ parent = *p;
+ entry = rb_entry(parent, struct full_stripe_lock, node);
+ if (fstripe_logical < entry->logical) {
+ p = &(*p)->rb_left;
+ } else if (fstripe_logical > entry->logical) {
+ p = &(*p)->rb_right;
+ } else {
+ entry->refs++;
+ return entry;
+ }
+ }
+
+ /* Insert new lock */
+ ret = kmalloc(sizeof(*ret), GFP_KERNEL);
+ if (!ret)
+ return ERR_PTR(-ENOMEM);
+ ret->logical = fstripe_logical;
+ ret->refs = 1;
+ mutex_init(&ret->mutex);
+
+ rb_link_node(&ret->node, parent, p);
+ rb_insert_color(&ret->node, &locks_root->root);
+ return ret;
+}
+
+/*
+ * Search for a full stripe lock of a block group
+ *
+ * Return pointer to existing full stripe lock if found
+ * Return NULL if not found
+ */
+static struct full_stripe_lock *search_full_stripe_lock(
+ struct btrfs_full_stripe_locks_tree *locks_root,
+ u64 fstripe_logical)
+{
+ struct rb_node *node;
+ struct full_stripe_lock *entry;
+
+ WARN_ON(!mutex_is_locked(&locks_root->lock));
+
+ node = locks_root->root.rb_node;
+ while (node) {
+ entry = rb_entry(node, struct full_stripe_lock, node);
+ if (fstripe_logical < entry->logical)
+ node = node->rb_left;
+ else if (fstripe_logical > entry->logical)
+ node = node->rb_right;
+ else
+ return entry;
+ }
+ return NULL;
+}
+
+/*
+ * Helper to get full stripe logical from a normal bytenr.
+ *
+ * Caller must ensure @cache is a RAID56 block group.
+ */
+static u64 get_full_stripe_logical(struct btrfs_block_group_cache *cache,
+ u64 bytenr)
+{
+ u64 ret;
+
+ /*
+ * round_down() can only handle power of 2, while RAID56 full
+ * stripe len can be 64KiB * n, so need manual round down.
+ */
+ ret = (bytenr - cache->key.objectid) / cache->full_stripe_len *
+ cache->full_stripe_len + cache->key.objectid;
+ return ret;
+}
+
+/*
+ * To lock a full stripe to avoid concurrency of recovery and read
+ * It's only used for profiles with parities(RAID5/6), for other profiles it
+ * does nothing
+ *
+ * Return 0 if we locked full stripe covering @bytenr, with a mutex hold.
+ * So caller must call unlock_full_stripe() at the same context.
+ *
+ * Return <0 if encounters error.
+ */
+static int lock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr,
+ bool *locked_ret)
+{
+ struct btrfs_block_group_cache *bg_cache;
+ struct btrfs_full_stripe_locks_tree *locks_root;
+ struct full_stripe_lock *existing;
+ u64 fstripe_start;
+ int ret = 0;
+
+ *locked_ret = false;
+ bg_cache = btrfs_lookup_block_group(fs_info, bytenr);
+ if (!bg_cache) {
+ WARN_ON(1);
+ return -ENOENT;
+ }
+
+ /* Profiles not based on parity don't need full stripe lock */
+ if (!(bg_cache->flags & BTRFS_BLOCK_GROUP_RAID56_MASK))
+ goto out;
+ locks_root = &bg_cache->full_stripe_locks_root;
+
+ fstripe_start = get_full_stripe_logical(bg_cache, bytenr);
+
+ /* Now insert the full stripe lock */
+ mutex_lock(&locks_root->lock);
+ existing = insert_full_stripe_lock(locks_root, fstripe_start);
+ mutex_unlock(&locks_root->lock);
+ if (IS_ERR(existing)) {
+ ret = PTR_ERR(existing);
+ goto out;
+ }
+ mutex_lock(&existing->mutex);
+ *locked_ret = true;
+out:
+ btrfs_put_block_group(bg_cache);
+ return ret;
+}
+
+/*
+ * Unlock a full stripe.
+ * NOTE: Caller must ensure it's the same context calling corresponding
+ * lock_full_stripe().
+ *
+ * Return 0 if we unlock full stripe without problem.
+ * Return <0 for error
+ */
+static int unlock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr,
+ bool locked)
+{
+ struct btrfs_block_group_cache *bg_cache;
+ struct btrfs_full_stripe_locks_tree *locks_root;
+ struct full_stripe_lock *fstripe_lock;
+ u64 fstripe_start;
+ bool freeit = false;
+ int ret = 0;
+
+ /* If we didn't acquire full stripe lock, no need to continue */
+ if (!locked)
+ return 0;
+
+ bg_cache = btrfs_lookup_block_group(fs_info, bytenr);
+ if (!bg_cache) {
+ WARN_ON(1);
+ return -ENOENT;
+ }
+ if (!(bg_cache->flags & BTRFS_BLOCK_GROUP_RAID56_MASK))
+ goto out;
+
+ locks_root = &bg_cache->full_stripe_locks_root;
+ fstripe_start = get_full_stripe_logical(bg_cache, bytenr);
+ if (ret < 0)
+ goto out;
+
+ mutex_lock(&locks_root->lock);
+ fstripe_lock = search_full_stripe_lock(locks_root, fstripe_start);
+ /* Unpaired unlock_full_stripe() detected */
+ if (!fstripe_lock) {
+ WARN_ON(1);
+ ret = -ENOENT;
+ mutex_unlock(&locks_root->lock);
+ goto out;
+ }
+
+ if (fstripe_lock->refs == 0) {
+ WARN_ON(1);
+ btrfs_warn(fs_info, "full stripe lock at %llu refcount underflow",
+ fstripe_lock->logical);
+ } else {
+ fstripe_lock->refs--;
+ }
+
+ if (fstripe_lock->refs == 0) {
+ rb_erase(&fstripe_lock->node, &locks_root->root);
+ freeit = true;
+ }
+ mutex_unlock(&locks_root->lock);
+
+ mutex_unlock(&fstripe_lock->mutex);
+ if (freeit)
+ kfree(fstripe_lock);
+out:
+ btrfs_put_block_group(bg_cache);
+ return ret;
+}
+
+/*
* used for workers that require transaction commits (i.e., for the
* NOCOW case)
*/
--
2.12.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56
2017-03-30 6:32 ` [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56 Qu Wenruo
@ 2017-03-30 16:49 ` Liu Bo
2017-03-31 1:29 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: Liu Bo @ 2017-03-30 16:49 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
On Thu, Mar 30, 2017 at 02:32:47PM +0800, Qu Wenruo wrote:
> Unlike mirror based profiles, RAID5/6 recovery needs to read out the
> whole full stripe.
>
> And if we don't do proper protect, it can easily cause race condition.
>
> Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
> for RAID5/6.
> Which stores a rb_tree of mutex for full stripes, so scrub callers can
> use them to lock a full stripe to avoid race.
>
> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
> ---
> fs/btrfs/ctree.h | 17 ++++
> fs/btrfs/extent-tree.c | 11 +++
> fs/btrfs/scrub.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 245 insertions(+)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 29b7fc28c607..9fe56da21fed 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -538,6 +538,14 @@ struct btrfs_io_ctl {
> unsigned check_crcs:1;
> };
>
> +/*
> + * Tree to record all locked full stripes of a RAID5/6 block group
> + */
> +struct btrfs_full_stripe_locks_tree {
> + struct rb_root root;
> + struct mutex lock;
> +};
> +
> struct btrfs_block_group_cache {
> struct btrfs_key key;
> struct btrfs_block_group_item item;
> @@ -648,6 +656,9 @@ struct btrfs_block_group_cache {
> * Protected by free_space_lock.
> */
> int needs_free_space;
> +
> + /* Record locked full stripes for RAID5/6 block group */
> + struct btrfs_full_stripe_locks_tree full_stripe_locks_root;
> };
>
> /* delayed seq elem */
> @@ -3647,6 +3658,12 @@ int btrfs_scrub_cancel_dev(struct btrfs_fs_info *info,
> struct btrfs_device *dev);
> int btrfs_scrub_progress(struct btrfs_fs_info *fs_info, u64 devid,
> struct btrfs_scrub_progress *progress);
> +static inline void btrfs_init_full_stripe_locks_tree(
> + struct btrfs_full_stripe_locks_tree *locks_root)
> +{
> + locks_root->root = RB_ROOT;
> + mutex_init(&locks_root->lock);
> +}
>
> /* dev-replace.c */
> void btrfs_bio_counter_inc_blocked(struct btrfs_fs_info *fs_info);
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index be5477676cc8..5f51ce81f484 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -131,6 +131,16 @@ void btrfs_put_block_group(struct btrfs_block_group_cache *cache)
> if (atomic_dec_and_test(&cache->count)) {
> WARN_ON(cache->pinned > 0);
> WARN_ON(cache->reserved > 0);
> +
> + /*
> + * If not empty, someone is still holding mutex of
> + * full_stripe_lock, which can only be released by caller.
> + * And it will definitely cause use-after-free when caller
> + * tries to release full stripe lock.
> + *
> + * No better way to resolve, but only to warn.
> + */
> + WARN_ON(!RB_EMPTY_ROOT(&cache->full_stripe_locks_root.root));
> kfree(cache->free_space_ctl);
> kfree(cache);
> }
> @@ -9917,6 +9927,7 @@ btrfs_create_block_group_cache(struct btrfs_fs_info *fs_info,
> btrfs_init_free_space_ctl(cache);
> atomic_set(&cache->trimming, 0);
> mutex_init(&cache->free_space_lock);
> + btrfs_init_full_stripe_locks_tree(&cache->full_stripe_locks_root);
>
> return cache;
> }
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index b0251eb1239f..5fc99a92b4ff 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -240,6 +240,13 @@ struct scrub_warning {
> struct btrfs_device *dev;
> };
>
> +struct full_stripe_lock {
> + struct rb_node node;
> + u64 logical;
> + u64 refs;
> + struct mutex mutex;
> +};
> +
> static void scrub_pending_bio_inc(struct scrub_ctx *sctx);
> static void scrub_pending_bio_dec(struct scrub_ctx *sctx);
> static void scrub_pending_trans_workers_inc(struct scrub_ctx *sctx);
> @@ -349,6 +356,216 @@ static void scrub_blocked_if_needed(struct btrfs_fs_info *fs_info)
> }
>
> /*
> + * Insert new full stripe lock into full stripe locks tree
> + *
> + * Return pointer to existing or newly inserted full_stripe_lock structure if
> + * everything works well.
> + * Return ERR_PTR(-ENOMEM) if we failed to allocate memory
> + *
> + * NOTE: caller must hold full_stripe_locks_root->lock before calling this
> + * function
> + */
> +static struct full_stripe_lock *insert_full_stripe_lock(
> + struct btrfs_full_stripe_locks_tree *locks_root,
> + u64 fstripe_logical)
> +{
> + struct rb_node **p;
> + struct rb_node *parent = NULL;
> + struct full_stripe_lock *entry;
> + struct full_stripe_lock *ret;
> +
> + WARN_ON(!mutex_is_locked(&locks_root->lock));
> +
> + p = &locks_root->root.rb_node;
> + while (*p) {
> + parent = *p;
> + entry = rb_entry(parent, struct full_stripe_lock, node);
> + if (fstripe_logical < entry->logical) {
> + p = &(*p)->rb_left;
> + } else if (fstripe_logical > entry->logical) {
> + p = &(*p)->rb_right;
> + } else {
> + entry->refs++;
> + return entry;
> + }
> + }
> +
> + /* Insert new lock */
> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
> + if (!ret)
> + return ERR_PTR(-ENOMEM);
> + ret->logical = fstripe_logical;
> + ret->refs = 1;
> + mutex_init(&ret->mutex);
> +
> + rb_link_node(&ret->node, parent, p);
> + rb_insert_color(&ret->node, &locks_root->root);
> + return ret;
> +}
> +
> +/*
> + * Search for a full stripe lock of a block group
> + *
> + * Return pointer to existing full stripe lock if found
> + * Return NULL if not found
> + */
> +static struct full_stripe_lock *search_full_stripe_lock(
> + struct btrfs_full_stripe_locks_tree *locks_root,
> + u64 fstripe_logical)
> +{
> + struct rb_node *node;
> + struct full_stripe_lock *entry;
> +
> + WARN_ON(!mutex_is_locked(&locks_root->lock));
> +
> + node = locks_root->root.rb_node;
> + while (node) {
> + entry = rb_entry(node, struct full_stripe_lock, node);
> + if (fstripe_logical < entry->logical)
> + node = node->rb_left;
> + else if (fstripe_logical > entry->logical)
> + node = node->rb_right;
> + else
> + return entry;
> + }
> + return NULL;
> +}
> +
> +/*
> + * Helper to get full stripe logical from a normal bytenr.
> + *
> + * Caller must ensure @cache is a RAID56 block group.
> + */
> +static u64 get_full_stripe_logical(struct btrfs_block_group_cache *cache,
> + u64 bytenr)
> +{
> + u64 ret;
> +
> + /*
> + * round_down() can only handle power of 2, while RAID56 full
> + * stripe len can be 64KiB * n, so need manual round down.
> + */
> + ret = (bytenr - cache->key.objectid) / cache->full_stripe_len *
> + cache->full_stripe_len + cache->key.objectid;
Can you please use div_u64 instead? '/' would cause building errors.
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Thanks,
-liubo
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56
2017-03-30 16:49 ` Liu Bo
@ 2017-03-31 1:29 ` Qu Wenruo
2017-03-31 17:34 ` Liu Bo
0 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2017-03-31 1:29 UTC (permalink / raw)
To: bo.li.liu; +Cc: linux-btrfs
At 03/31/2017 12:49 AM, Liu Bo wrote:
> On Thu, Mar 30, 2017 at 02:32:47PM +0800, Qu Wenruo wrote:
>> Unlike mirror based profiles, RAID5/6 recovery needs to read out the
>> whole full stripe.
>>
>> And if we don't do proper protect, it can easily cause race condition.
>>
>> Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
>> for RAID5/6.
>> Which stores a rb_tree of mutex for full stripes, so scrub callers can
>> use them to lock a full stripe to avoid race.
>>
>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>> ---
>> fs/btrfs/ctree.h | 17 ++++
>> fs/btrfs/extent-tree.c | 11 +++
>> fs/btrfs/scrub.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 245 insertions(+)
>>
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index 29b7fc28c607..9fe56da21fed 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -538,6 +538,14 @@ struct btrfs_io_ctl {
>> unsigned check_crcs:1;
>> };
>>
>> +/*
>> + * Tree to record all locked full stripes of a RAID5/6 block group
>> + */
>> +struct btrfs_full_stripe_locks_tree {
>> + struct rb_root root;
>> + struct mutex lock;
>> +};
>> +
>> struct btrfs_block_group_cache {
>> struct btrfs_key key;
>> struct btrfs_block_group_item item;
>> @@ -648,6 +656,9 @@ struct btrfs_block_group_cache {
>> * Protected by free_space_lock.
>> */
>> int needs_free_space;
>> +
>> + /* Record locked full stripes for RAID5/6 block group */
>> + struct btrfs_full_stripe_locks_tree full_stripe_locks_root;
>> };
>>
>> /* delayed seq elem */
>> @@ -3647,6 +3658,12 @@ int btrfs_scrub_cancel_dev(struct btrfs_fs_info *info,
>> struct btrfs_device *dev);
>> int btrfs_scrub_progress(struct btrfs_fs_info *fs_info, u64 devid,
>> struct btrfs_scrub_progress *progress);
>> +static inline void btrfs_init_full_stripe_locks_tree(
>> + struct btrfs_full_stripe_locks_tree *locks_root)
>> +{
>> + locks_root->root = RB_ROOT;
>> + mutex_init(&locks_root->lock);
>> +}
>>
>> /* dev-replace.c */
>> void btrfs_bio_counter_inc_blocked(struct btrfs_fs_info *fs_info);
>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
>> index be5477676cc8..5f51ce81f484 100644
>> --- a/fs/btrfs/extent-tree.c
>> +++ b/fs/btrfs/extent-tree.c
>> @@ -131,6 +131,16 @@ void btrfs_put_block_group(struct btrfs_block_group_cache *cache)
>> if (atomic_dec_and_test(&cache->count)) {
>> WARN_ON(cache->pinned > 0);
>> WARN_ON(cache->reserved > 0);
>> +
>> + /*
>> + * If not empty, someone is still holding mutex of
>> + * full_stripe_lock, which can only be released by caller.
>> + * And it will definitely cause use-after-free when caller
>> + * tries to release full stripe lock.
>> + *
>> + * No better way to resolve, but only to warn.
>> + */
>> + WARN_ON(!RB_EMPTY_ROOT(&cache->full_stripe_locks_root.root));
>> kfree(cache->free_space_ctl);
>> kfree(cache);
>> }
>> @@ -9917,6 +9927,7 @@ btrfs_create_block_group_cache(struct btrfs_fs_info *fs_info,
>> btrfs_init_free_space_ctl(cache);
>> atomic_set(&cache->trimming, 0);
>> mutex_init(&cache->free_space_lock);
>> + btrfs_init_full_stripe_locks_tree(&cache->full_stripe_locks_root);
>>
>> return cache;
>> }
>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
>> index b0251eb1239f..5fc99a92b4ff 100644
>> --- a/fs/btrfs/scrub.c
>> +++ b/fs/btrfs/scrub.c
>> @@ -240,6 +240,13 @@ struct scrub_warning {
>> struct btrfs_device *dev;
>> };
>>
>> +struct full_stripe_lock {
>> + struct rb_node node;
>> + u64 logical;
>> + u64 refs;
>> + struct mutex mutex;
>> +};
>> +
>> static void scrub_pending_bio_inc(struct scrub_ctx *sctx);
>> static void scrub_pending_bio_dec(struct scrub_ctx *sctx);
>> static void scrub_pending_trans_workers_inc(struct scrub_ctx *sctx);
>> @@ -349,6 +356,216 @@ static void scrub_blocked_if_needed(struct btrfs_fs_info *fs_info)
>> }
>>
>> /*
>> + * Insert new full stripe lock into full stripe locks tree
>> + *
>> + * Return pointer to existing or newly inserted full_stripe_lock structure if
>> + * everything works well.
>> + * Return ERR_PTR(-ENOMEM) if we failed to allocate memory
>> + *
>> + * NOTE: caller must hold full_stripe_locks_root->lock before calling this
>> + * function
>> + */
>> +static struct full_stripe_lock *insert_full_stripe_lock(
>> + struct btrfs_full_stripe_locks_tree *locks_root,
>> + u64 fstripe_logical)
>> +{
>> + struct rb_node **p;
>> + struct rb_node *parent = NULL;
>> + struct full_stripe_lock *entry;
>> + struct full_stripe_lock *ret;
>> +
>> + WARN_ON(!mutex_is_locked(&locks_root->lock));
>> +
>> + p = &locks_root->root.rb_node;
>> + while (*p) {
>> + parent = *p;
>> + entry = rb_entry(parent, struct full_stripe_lock, node);
>> + if (fstripe_logical < entry->logical) {
>> + p = &(*p)->rb_left;
>> + } else if (fstripe_logical > entry->logical) {
>> + p = &(*p)->rb_right;
>> + } else {
>> + entry->refs++;
>> + return entry;
>> + }
>> + }
>> +
>> + /* Insert new lock */
>> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
>> + if (!ret)
>> + return ERR_PTR(-ENOMEM);
>> + ret->logical = fstripe_logical;
>> + ret->refs = 1;
>> + mutex_init(&ret->mutex);
>> +
>> + rb_link_node(&ret->node, parent, p);
>> + rb_insert_color(&ret->node, &locks_root->root);
>> + return ret;
>> +}
>> +
>> +/*
>> + * Search for a full stripe lock of a block group
>> + *
>> + * Return pointer to existing full stripe lock if found
>> + * Return NULL if not found
>> + */
>> +static struct full_stripe_lock *search_full_stripe_lock(
>> + struct btrfs_full_stripe_locks_tree *locks_root,
>> + u64 fstripe_logical)
>> +{
>> + struct rb_node *node;
>> + struct full_stripe_lock *entry;
>> +
>> + WARN_ON(!mutex_is_locked(&locks_root->lock));
>> +
>> + node = locks_root->root.rb_node;
>> + while (node) {
>> + entry = rb_entry(node, struct full_stripe_lock, node);
>> + if (fstripe_logical < entry->logical)
>> + node = node->rb_left;
>> + else if (fstripe_logical > entry->logical)
>> + node = node->rb_right;
>> + else
>> + return entry;
>> + }
>> + return NULL;
>> +}
>> +
>> +/*
>> + * Helper to get full stripe logical from a normal bytenr.
>> + *
>> + * Caller must ensure @cache is a RAID56 block group.
>> + */
>> +static u64 get_full_stripe_logical(struct btrfs_block_group_cache *cache,
>> + u64 bytenr)
>> +{
>> + u64 ret;
>> +
>> + /*
>> + * round_down() can only handle power of 2, while RAID56 full
>> + * stripe len can be 64KiB * n, so need manual round down.
>> + */
>> + ret = (bytenr - cache->key.objectid) / cache->full_stripe_len *
>> + cache->full_stripe_len + cache->key.objectid;
>
> Can you please use div_u64 instead? '/' would cause building errors.
No problem, but I'm still curious about under which arch/compiler it
would cause build error?
Thanks,
Qu
>
> Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>
> Thanks,
>
> -liubo
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56
2017-03-31 1:29 ` Qu Wenruo
@ 2017-03-31 17:34 ` Liu Bo
2017-04-03 0:48 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: Liu Bo @ 2017-03-31 17:34 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
On Fri, Mar 31, 2017 at 09:29:20AM +0800, Qu Wenruo wrote:
>
>
> At 03/31/2017 12:49 AM, Liu Bo wrote:
> > On Thu, Mar 30, 2017 at 02:32:47PM +0800, Qu Wenruo wrote:
> > > Unlike mirror based profiles, RAID5/6 recovery needs to read out the
> > > whole full stripe.
> > >
> > > And if we don't do proper protect, it can easily cause race condition.
> > >
> > > Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
> > > for RAID5/6.
> > > Which stores a rb_tree of mutex for full stripes, so scrub callers can
> > > use them to lock a full stripe to avoid race.
> > >
> > > Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> > > Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
> > > ---
> > > fs/btrfs/ctree.h | 17 ++++
> > > fs/btrfs/extent-tree.c | 11 +++
> > > fs/btrfs/scrub.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 245 insertions(+)
> > >
> > > diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> > > index 29b7fc28c607..9fe56da21fed 100644
> > > --- a/fs/btrfs/ctree.h
> > > +++ b/fs/btrfs/ctree.h
[...]
> > > +/*
> > > + * Helper to get full stripe logical from a normal bytenr.
> > > + *
> > > + * Caller must ensure @cache is a RAID56 block group.
> > > + */
> > > +static u64 get_full_stripe_logical(struct btrfs_block_group_cache *cache,
> > > + u64 bytenr)
> > > +{
> > > + u64 ret;
> > > +
> > > + /*
> > > + * round_down() can only handle power of 2, while RAID56 full
> > > + * stripe len can be 64KiB * n, so need manual round down.
> > > + */
> > > + ret = (bytenr - cache->key.objectid) / cache->full_stripe_len *
> > > + cache->full_stripe_len + cache->key.objectid;
> >
> > Can you please use div_u64 instead? '/' would cause building errors.
>
> No problem, but I'm still curious about under which arch/compiler it would
> cause build error?
>
Sorry, it should be div64_u64 since cache->full_stripe_len is (unsigend long).
Building errors might not be true, it's from my memory.
But in runtime, it could end up with 'divide error'.
Thanks,
-liubo
> Thanks,
> Qu
> >
> > Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
> >
> > Thanks,
> >
> > -liubo
> >
> >
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56
2017-03-31 17:34 ` Liu Bo
@ 2017-04-03 0:48 ` Qu Wenruo
0 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2017-04-03 0:48 UTC (permalink / raw)
To: bo.li.liu; +Cc: linux-btrfs
At 04/01/2017 01:34 AM, Liu Bo wrote:
> On Fri, Mar 31, 2017 at 09:29:20AM +0800, Qu Wenruo wrote:
>>
>>
>> At 03/31/2017 12:49 AM, Liu Bo wrote:
>>> On Thu, Mar 30, 2017 at 02:32:47PM +0800, Qu Wenruo wrote:
>>>> Unlike mirror based profiles, RAID5/6 recovery needs to read out the
>>>> whole full stripe.
>>>>
>>>> And if we don't do proper protect, it can easily cause race condition.
>>>>
>>>> Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
>>>> for RAID5/6.
>>>> Which stores a rb_tree of mutex for full stripes, so scrub callers can
>>>> use them to lock a full stripe to avoid race.
>>>>
>>>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>>>> Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>>>> ---
>>>> fs/btrfs/ctree.h | 17 ++++
>>>> fs/btrfs/extent-tree.c | 11 +++
>>>> fs/btrfs/scrub.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 245 insertions(+)
>>>>
>>>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>>>> index 29b7fc28c607..9fe56da21fed 100644
>>>> --- a/fs/btrfs/ctree.h
>>>> +++ b/fs/btrfs/ctree.h
> [...]
>>>> +/*
>>>> + * Helper to get full stripe logical from a normal bytenr.
>>>> + *
>>>> + * Caller must ensure @cache is a RAID56 block group.
>>>> + */
>>>> +static u64 get_full_stripe_logical(struct btrfs_block_group_cache *cache,
>>>> + u64 bytenr)
>>>> +{
>>>> + u64 ret;
>>>> +
>>>> + /*
>>>> + * round_down() can only handle power of 2, while RAID56 full
>>>> + * stripe len can be 64KiB * n, so need manual round down.
>>>> + */
>>>> + ret = (bytenr - cache->key.objectid) / cache->full_stripe_len *
>>>> + cache->full_stripe_len + cache->key.objectid;
>>>
>>> Can you please use div_u64 instead? '/' would cause building errors.
>>
>> No problem, but I'm still curious about under which arch/compiler it would
>> cause build error?
>>
>
> Sorry, it should be div64_u64 since cache->full_stripe_len is (unsigend long).
In theory, yes we should use div64_u64.
But I strongly doubt if we can overflow u32 in full_stripe_len context.
For current fixed 64K stripe len, we need 65536 data stripes, which
should make chunk_item larger than any node size.
IIRC years ago, we have introduced extra chunk item and super array size
check to avoid such case.
So we should be safe to use div_u64.
Anyway, I'll add extra check before calling div, and still use div64_u64
just in case.
Thanks for pointing this out,
Qu
>
> Building errors might not be true, it's from my memory.
> But in runtime, it could end up with 'divide error'.
>
> Thanks,
>
> -liubo
>
>> Thanks,
>> Qu
>>>
>>> Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>>>
>>> Thanks,
>>>
>>> -liubo
>>>
>>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition
2017-03-30 6:32 [PATCH v4 0/5] raid56: scrub related fixes Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56 Qu Wenruo
@ 2017-03-30 6:32 ` Qu Wenruo
2017-03-30 17:05 ` Liu Bo
2017-03-30 6:32 ` [PATCH v4 3/5] btrfs: scrub: Don't append on-disk pages for raid56 scrub Qu Wenruo
` (2 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2017-03-30 6:32 UTC (permalink / raw)
To: linux-btrfs; +Cc: bo.li.liu
When scrubbing a RAID5 which has recoverable data corruption (only one
data stripe is corrupted), sometimes scrub will report more csum errors
than expected. Sometimes even unrecoverable error will be reported.
The problem can be easily reproduced by the following steps:
1) Create a btrfs with RAID5 data profile with 3 devs
2) Mount it with nospace_cache or space_cache=v2
To avoid extra data space usage.
3) Create a 128K file and sync the fs, unmount it
Now the 128K file lies at the beginning of the data chunk
4) Locate the physical bytenr of data chunk on dev3
Dev3 is the 1st data stripe.
5) Corrupt the first 64K of the data chunk stripe on dev3
6) Mount the fs and scrub it
The correct csum error number should be 16(assuming using x86_64).
Larger csum error number can be reported in a 1/3 chance.
And unrecoverable error can also be reported in a 1/10 chance.
The root cause of the problem is RAID5/6 recover code has race
condition, due to the fact that full scrub is initiated per device.
While for other mirror based profiles, each mirror is independent with
each other, so race won't cause any big problem.
For example:
Corrupted | Correct | Correct |
| Scrub dev3 (D1) | Scrub dev2 (D2) | Scrub dev1(P) |
------------------------------------------------------------------------
Read out D1 |Read out D2 |Read full stripe |
Check csum |Check csum |Check parity |
Csum mismatch |Csum match, continue |Parity mismatch |
handle_errored_block | |handle_errored_block |
Read out full stripe | | Read out full stripe|
D1 csum error(err++) | | D1 csum error(err++)|
Recover D1 | | Recover D1 |
So D1's csum error is accounted twice, just because
handle_errored_block() doesn't have enough protect, and race can happen.
On even worse case, for example D1's recovery code is re-writing
D1/D2/P, and P's recovery code is just reading out full stripe, then we
can cause unrecoverable error.
This patch will use previously introduced lock_full_stripe() and
unlock_full_stripe() to protect the whole scrub_handle_errored_block()
function for RAID56 recovery.
So no extra csum error nor unrecoverable error.
Reported-by: Goffredo Baroncelli <kreijack@libero.it>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
---
fs/btrfs/scrub.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 5fc99a92b4ff..4bbefc96485d 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1109,6 +1109,7 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
int mirror_index;
int page_num;
int success;
+ bool full_stripe_locked;
static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
DEFAULT_RATELIMIT_BURST);
@@ -1134,6 +1135,25 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
have_csum = sblock_to_check->pagev[0]->have_csum;
dev = sblock_to_check->pagev[0]->dev;
+ /*
+ * For RAID5/6 race can happen for different dev scrub thread.
+ * For data corruption, Parity and Data thread will both try
+ * to recovery the data.
+ * Race can lead to double added csum error, or even unrecoverable
+ * error.
+ */
+ ret = lock_full_stripe(fs_info, logical, &full_stripe_locked);
+ if (ret < 0) {
+ spin_lock(&sctx->stat_lock);
+ /* Either malloc failure or bg_cache not found */
+ if (ret == -ENOMEM)
+ sctx->stat.malloc_errors++;
+ else
+ sctx->stat.uncorrectable_errors++;
+ spin_unlock(&sctx->stat_lock);
+ return ret;
+ }
+
if (sctx->is_dev_replace && !is_metadata && !have_csum) {
sblocks_for_recheck = NULL;
goto nodatasum_case;
@@ -1468,6 +1488,9 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
kfree(sblocks_for_recheck);
}
+ ret = unlock_full_stripe(fs_info, logical, full_stripe_locked);
+ if (ret < 0)
+ return ret;
return 0;
}
--
2.12.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition
2017-03-30 6:32 ` [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition Qu Wenruo
@ 2017-03-30 17:05 ` Liu Bo
2017-03-31 0:25 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: Liu Bo @ 2017-03-30 17:05 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
On Thu, Mar 30, 2017 at 02:32:48PM +0800, Qu Wenruo wrote:
> When scrubbing a RAID5 which has recoverable data corruption (only one
> data stripe is corrupted), sometimes scrub will report more csum errors
> than expected. Sometimes even unrecoverable error will be reported.
>
> The problem can be easily reproduced by the following steps:
> 1) Create a btrfs with RAID5 data profile with 3 devs
> 2) Mount it with nospace_cache or space_cache=v2
> To avoid extra data space usage.
> 3) Create a 128K file and sync the fs, unmount it
> Now the 128K file lies at the beginning of the data chunk
> 4) Locate the physical bytenr of data chunk on dev3
> Dev3 is the 1st data stripe.
> 5) Corrupt the first 64K of the data chunk stripe on dev3
> 6) Mount the fs and scrub it
>
> The correct csum error number should be 16(assuming using x86_64).
> Larger csum error number can be reported in a 1/3 chance.
> And unrecoverable error can also be reported in a 1/10 chance.
>
> The root cause of the problem is RAID5/6 recover code has race
> condition, due to the fact that full scrub is initiated per device.
>
> While for other mirror based profiles, each mirror is independent with
> each other, so race won't cause any big problem.
>
> For example:
> Corrupted | Correct | Correct |
> | Scrub dev3 (D1) | Scrub dev2 (D2) | Scrub dev1(P) |
> ------------------------------------------------------------------------
> Read out D1 |Read out D2 |Read full stripe |
> Check csum |Check csum |Check parity |
> Csum mismatch |Csum match, continue |Parity mismatch |
> handle_errored_block | |handle_errored_block |
> Read out full stripe | | Read out full stripe|
> D1 csum error(err++) | | D1 csum error(err++)|
> Recover D1 | | Recover D1 |
>
> So D1's csum error is accounted twice, just because
> handle_errored_block() doesn't have enough protect, and race can happen.
>
> On even worse case, for example D1's recovery code is re-writing
> D1/D2/P, and P's recovery code is just reading out full stripe, then we
> can cause unrecoverable error.
>
> This patch will use previously introduced lock_full_stripe() and
> unlock_full_stripe() to protect the whole scrub_handle_errored_block()
> function for RAID56 recovery.
> So no extra csum error nor unrecoverable error.
>
> Reported-by: Goffredo Baroncelli <kreijack@libero.it>
> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> ---
> fs/btrfs/scrub.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index 5fc99a92b4ff..4bbefc96485d 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -1109,6 +1109,7 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
> int mirror_index;
> int page_num;
> int success;
> + bool full_stripe_locked;
> static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
>
> @@ -1134,6 +1135,25 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
> have_csum = sblock_to_check->pagev[0]->have_csum;
> dev = sblock_to_check->pagev[0]->dev;
>
> + /*
> + * For RAID5/6 race can happen for different dev scrub thread.
> + * For data corruption, Parity and Data thread will both try
> + * to recovery the data.
> + * Race can lead to double added csum error, or even unrecoverable
> + * error.
> + */
> + ret = lock_full_stripe(fs_info, logical, &full_stripe_locked);
> + if (ret < 0) {
> + spin_lock(&sctx->stat_lock);
> + /* Either malloc failure or bg_cache not found */
> + if (ret == -ENOMEM)
> + sctx->stat.malloc_errors++;
> + else
> + sctx->stat.uncorrectable_errors++;
Other places in scrub_handle_errored_block() also set read_errors and
uncorrectable_errors, why the above is an exception?
I'm fine with putting a bool into lock_full_stripe(), but it's easier
to tell whether locking is successful by setting the flag after
locking.
Thanks,
-liubo
> + spin_unlock(&sctx->stat_lock);
> + return ret;
> + }
> +
> if (sctx->is_dev_replace && !is_metadata && !have_csum) {
> sblocks_for_recheck = NULL;
> goto nodatasum_case;
> @@ -1468,6 +1488,9 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
> kfree(sblocks_for_recheck);
> }
>
> + ret = unlock_full_stripe(fs_info, logical, full_stripe_locked);
> + if (ret < 0)
> + return ret;
> return 0;
> }
>
> --
> 2.12.1
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition
2017-03-30 17:05 ` Liu Bo
@ 2017-03-31 0:25 ` Qu Wenruo
2017-03-31 1:40 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2017-03-31 0:25 UTC (permalink / raw)
To: bo.li.liu; +Cc: linux-btrfs
At 03/31/2017 01:05 AM, Liu Bo wrote:
> On Thu, Mar 30, 2017 at 02:32:48PM +0800, Qu Wenruo wrote:
>> When scrubbing a RAID5 which has recoverable data corruption (only one
>> data stripe is corrupted), sometimes scrub will report more csum errors
>> than expected. Sometimes even unrecoverable error will be reported.
>>
>> The problem can be easily reproduced by the following steps:
>> 1) Create a btrfs with RAID5 data profile with 3 devs
>> 2) Mount it with nospace_cache or space_cache=v2
>> To avoid extra data space usage.
>> 3) Create a 128K file and sync the fs, unmount it
>> Now the 128K file lies at the beginning of the data chunk
>> 4) Locate the physical bytenr of data chunk on dev3
>> Dev3 is the 1st data stripe.
>> 5) Corrupt the first 64K of the data chunk stripe on dev3
>> 6) Mount the fs and scrub it
>>
>> The correct csum error number should be 16(assuming using x86_64).
>> Larger csum error number can be reported in a 1/3 chance.
>> And unrecoverable error can also be reported in a 1/10 chance.
>>
>> The root cause of the problem is RAID5/6 recover code has race
>> condition, due to the fact that full scrub is initiated per device.
>>
>> While for other mirror based profiles, each mirror is independent with
>> each other, so race won't cause any big problem.
>>
>> For example:
>> Corrupted | Correct | Correct |
>> | Scrub dev3 (D1) | Scrub dev2 (D2) | Scrub dev1(P) |
>> ------------------------------------------------------------------------
>> Read out D1 |Read out D2 |Read full stripe |
>> Check csum |Check csum |Check parity |
>> Csum mismatch |Csum match, continue |Parity mismatch |
>> handle_errored_block | |handle_errored_block |
>> Read out full stripe | | Read out full stripe|
>> D1 csum error(err++) | | D1 csum error(err++)|
>> Recover D1 | | Recover D1 |
>>
>> So D1's csum error is accounted twice, just because
>> handle_errored_block() doesn't have enough protect, and race can happen.
>>
>> On even worse case, for example D1's recovery code is re-writing
>> D1/D2/P, and P's recovery code is just reading out full stripe, then we
>> can cause unrecoverable error.
>>
>> This patch will use previously introduced lock_full_stripe() and
>> unlock_full_stripe() to protect the whole scrub_handle_errored_block()
>> function for RAID56 recovery.
>> So no extra csum error nor unrecoverable error.
>>
>> Reported-by: Goffredo Baroncelli <kreijack@libero.it>
>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> ---
>> fs/btrfs/scrub.c | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
>> index 5fc99a92b4ff..4bbefc96485d 100644
>> --- a/fs/btrfs/scrub.c
>> +++ b/fs/btrfs/scrub.c
>> @@ -1109,6 +1109,7 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
>> int mirror_index;
>> int page_num;
>> int success;
>> + bool full_stripe_locked;
>> static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
>> DEFAULT_RATELIMIT_BURST);
>>
>> @@ -1134,6 +1135,25 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
>> have_csum = sblock_to_check->pagev[0]->have_csum;
>> dev = sblock_to_check->pagev[0]->dev;
>>
>> + /*
>> + * For RAID5/6 race can happen for different dev scrub thread.
>> + * For data corruption, Parity and Data thread will both try
>> + * to recovery the data.
>> + * Race can lead to double added csum error, or even unrecoverable
>> + * error.
>> + */
>> + ret = lock_full_stripe(fs_info, logical, &full_stripe_locked);
>> + if (ret < 0) {
>> + spin_lock(&sctx->stat_lock);
>> + /* Either malloc failure or bg_cache not found */
>> + if (ret == -ENOMEM)
>> + sctx->stat.malloc_errors++;
>> + else
>> + sctx->stat.uncorrectable_errors++;
>
> Other places in scrub_handle_errored_block() also set read_errors and
> uncorrectable_errors, why the above is an exception?
Because we didn't even read out anything, so I don't think we need to
update read_errors here.
Even uncorrectable_errors here doesn't even look good to me.
Such -ENOENT error is unrelated to on-disk data, but runtime error which
freed the block group cache (maybe block group itself).
It is more like an assert for -ENOENT case.
However we don't have good enough states for this, I use
uncorrectable_error as fallback.
It would very nice if we have more appropriate member for this case.
>
> I'm fine with putting a bool into lock_full_stripe(), but it's easier
> to tell whether locking is successful by setting the flag after
> locking.
In fact, I prefer to make such bool internal, hidden from callers but
only affects the behavior of lock/unlock_full_stripe().
Caller should only care that lock must be paired with unlock, and block
group must exist, and don't forget to handle error.
Other than that, everything else should be handled by
lock/unlock_full_stripe() internally, user won't need to bother.
Thanks,
Qu
>
> Thanks,
>
> -liubo
>
>> + spin_unlock(&sctx->stat_lock);
>> + return ret;
>> + }
>> +
>> if (sctx->is_dev_replace && !is_metadata && !have_csum) {
>> sblocks_for_recheck = NULL;
>> goto nodatasum_case;
>> @@ -1468,6 +1488,9 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
>> kfree(sblocks_for_recheck);
>> }
>>
>> + ret = unlock_full_stripe(fs_info, logical, full_stripe_locked);
>> + if (ret < 0)
>> + return ret;
>> return 0;
>> }
>>
>> --
>> 2.12.1
>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition
2017-03-31 0:25 ` Qu Wenruo
@ 2017-03-31 1:40 ` Qu Wenruo
0 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2017-03-31 1:40 UTC (permalink / raw)
To: bo.li.liu; +Cc: linux-btrfs
At 03/31/2017 08:25 AM, Qu Wenruo wrote:
>
>
> At 03/31/2017 01:05 AM, Liu Bo wrote:
>> On Thu, Mar 30, 2017 at 02:32:48PM +0800, Qu Wenruo wrote:
>>> When scrubbing a RAID5 which has recoverable data corruption (only one
>>> data stripe is corrupted), sometimes scrub will report more csum errors
>>> than expected. Sometimes even unrecoverable error will be reported.
>>>
>>> The problem can be easily reproduced by the following steps:
>>> 1) Create a btrfs with RAID5 data profile with 3 devs
>>> 2) Mount it with nospace_cache or space_cache=v2
>>> To avoid extra data space usage.
>>> 3) Create a 128K file and sync the fs, unmount it
>>> Now the 128K file lies at the beginning of the data chunk
>>> 4) Locate the physical bytenr of data chunk on dev3
>>> Dev3 is the 1st data stripe.
>>> 5) Corrupt the first 64K of the data chunk stripe on dev3
>>> 6) Mount the fs and scrub it
>>>
>>> The correct csum error number should be 16(assuming using x86_64).
>>> Larger csum error number can be reported in a 1/3 chance.
>>> And unrecoverable error can also be reported in a 1/10 chance.
>>>
>>> The root cause of the problem is RAID5/6 recover code has race
>>> condition, due to the fact that full scrub is initiated per device.
>>>
>>> While for other mirror based profiles, each mirror is independent with
>>> each other, so race won't cause any big problem.
>>>
>>> For example:
>>> Corrupted | Correct | Correct |
>>> | Scrub dev3 (D1) | Scrub dev2 (D2) | Scrub dev1(P) |
>>> ------------------------------------------------------------------------
>>> Read out D1 |Read out D2 |Read full stripe |
>>> Check csum |Check csum |Check parity |
>>> Csum mismatch |Csum match, continue |Parity mismatch |
>>> handle_errored_block | |handle_errored_block |
>>> Read out full stripe | | Read out full stripe|
>>> D1 csum error(err++) | | D1 csum error(err++)|
>>> Recover D1 | | Recover D1 |
>>>
>>> So D1's csum error is accounted twice, just because
>>> handle_errored_block() doesn't have enough protect, and race can happen.
>>>
>>> On even worse case, for example D1's recovery code is re-writing
>>> D1/D2/P, and P's recovery code is just reading out full stripe, then we
>>> can cause unrecoverable error.
>>>
>>> This patch will use previously introduced lock_full_stripe() and
>>> unlock_full_stripe() to protect the whole scrub_handle_errored_block()
>>> function for RAID56 recovery.
>>> So no extra csum error nor unrecoverable error.
>>>
>>> Reported-by: Goffredo Baroncelli <kreijack@libero.it>
>>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>>> ---
>>> fs/btrfs/scrub.c | 23 +++++++++++++++++++++++
>>> 1 file changed, 23 insertions(+)
>>>
>>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
>>> index 5fc99a92b4ff..4bbefc96485d 100644
>>> --- a/fs/btrfs/scrub.c
>>> +++ b/fs/btrfs/scrub.c
>>> @@ -1109,6 +1109,7 @@ static int scrub_handle_errored_block(struct
>>> scrub_block *sblock_to_check)
>>> int mirror_index;
>>> int page_num;
>>> int success;
>>> + bool full_stripe_locked;
>>> static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
>>> DEFAULT_RATELIMIT_BURST);
>>>
>>> @@ -1134,6 +1135,25 @@ static int scrub_handle_errored_block(struct
>>> scrub_block *sblock_to_check)
>>> have_csum = sblock_to_check->pagev[0]->have_csum;
>>> dev = sblock_to_check->pagev[0]->dev;
>>>
>>> + /*
>>> + * For RAID5/6 race can happen for different dev scrub thread.
>>> + * For data corruption, Parity and Data thread will both try
>>> + * to recovery the data.
>>> + * Race can lead to double added csum error, or even unrecoverable
>>> + * error.
>>> + */
>>> + ret = lock_full_stripe(fs_info, logical, &full_stripe_locked);
>>> + if (ret < 0) {
>>> + spin_lock(&sctx->stat_lock);
>>> + /* Either malloc failure or bg_cache not found */
>>> + if (ret == -ENOMEM)
>>> + sctx->stat.malloc_errors++;
>>> + else
>>> + sctx->stat.uncorrectable_errors++;
>>
>> Other places in scrub_handle_errored_block() also set read_errors and
>> uncorrectable_errors, why the above is an exception?
>
> Because we didn't even read out anything, so I don't think we need to
> update read_errors here.
>
> Even uncorrectable_errors here doesn't even look good to me.
> Such -ENOENT error is unrelated to on-disk data, but runtime error which
> freed the block group cache (maybe block group itself).
>
> It is more like an assert for -ENOENT case.
>
> However we don't have good enough states for this, I use
> uncorrectable_error as fallback.
>
> It would very nice if we have more appropriate member for this case.
Please ignore this comment.
I foudn that sctx->stat treats any error prevents us from continue
reading as "read" error.
As long as we didn't do a successful read, then "read" error should be
increased, so in this case "read" error should also be increased.
So is "uncorrectable" errors.
I'll update them.
Thanks for pointing this out.
Qu
>
>>
>> I'm fine with putting a bool into lock_full_stripe(), but it's easier
>> to tell whether locking is successful by setting the flag after
>> locking.
>
> In fact, I prefer to make such bool internal, hidden from callers but
> only affects the behavior of lock/unlock_full_stripe().
>
> Caller should only care that lock must be paired with unlock, and block
> group must exist, and don't forget to handle error.
>
> Other than that, everything else should be handled by
> lock/unlock_full_stripe() internally, user won't need to bother.
>
> Thanks,
> Qu
>
>>
>> Thanks,
>>
>> -liubo
>>
>>> + spin_unlock(&sctx->stat_lock);
>>> + return ret;
>>> + }
>>> +
>>> if (sctx->is_dev_replace && !is_metadata && !have_csum) {
>>> sblocks_for_recheck = NULL;
>>> goto nodatasum_case;
>>> @@ -1468,6 +1488,9 @@ static int scrub_handle_errored_block(struct
>>> scrub_block *sblock_to_check)
>>> kfree(sblocks_for_recheck);
>>> }
>>>
>>> + ret = unlock_full_stripe(fs_info, logical, full_stripe_locked);
>>> + if (ret < 0)
>>> + return ret;
>>> return 0;
>>> }
>>>
>>> --
>>> 2.12.1
>>>
>>>
>>>
>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 3/5] btrfs: scrub: Don't append on-disk pages for raid56 scrub
2017-03-30 6:32 [PATCH v4 0/5] raid56: scrub related fixes Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 1/5] btrfs: scrub: Introduce full stripe lock for RAID56 Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 2/5] btrfs: scrub: Fix RAID56 recovery race condition Qu Wenruo
@ 2017-03-30 6:32 ` Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 4/5] btrfs: Wait flighting bio before freeing target device for raid56 Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 5/5] btrfs: Prevent scrub recheck from racing with dev replace Qu Wenruo
4 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2017-03-30 6:32 UTC (permalink / raw)
To: linux-btrfs; +Cc: bo.li.liu
In the following situation, scrub will calculate wrong parity to
overwrite correct one:
RAID5 full stripe:
Before
| Dev 1 | Dev 2 | Dev 3 |
| Data stripe 1 | Data stripe 2 | Parity Stripe |
--------------------------------------------------- 0
| 0x0000 (Bad) | 0xcdcd | 0x0000 |
--------------------------------------------------- 4K
| 0xcdcd | 0xcdcd | 0x0000 |
...
| 0xcdcd | 0xcdcd | 0x0000 |
--------------------------------------------------- 64K
After scrubbing dev3 only:
| Dev 1 | Dev 2 | Dev 3 |
| Data stripe 1 | Data stripe 2 | Parity Stripe |
--------------------------------------------------- 0
| 0xcdcd (Good) | 0xcdcd | 0xcdcd (Bad) |
--------------------------------------------------- 4K
| 0xcdcd | 0xcdcd | 0x0000 |
...
| 0xcdcd | 0xcdcd | 0x0000 |
--------------------------------------------------- 64K
The reason is after raid56 read rebuild rbio->stripe_pages are all
correct recovered (0xcd for data stripes).
However when we check and repair parity, in
scrub_parity_check_and_repair(), we will append pages in
sparity->spages list to rbio->bio_pages[], which contains old on-disk
data.
And when we submit parity data to disk, we calculate parity using
rbio->bio_pages[] first, if rbio->bio_pages[] is not found, then fallback
to rbio->stripe_pages[].
The patch fix it by not appending pages from sparity->spages.
So finish_parity_scrub() will use rbio->stripe_pages[] which is correct.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
---
fs/btrfs/scrub.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 4bbefc96485d..bffbe3ce7d70 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -3005,7 +3005,6 @@ static void scrub_parity_check_and_repair(struct scrub_parity *sparity)
struct btrfs_fs_info *fs_info = sctx->fs_info;
struct bio *bio;
struct btrfs_raid_bio *rbio;
- struct scrub_page *spage;
struct btrfs_bio *bbio = NULL;
u64 length;
int ret;
@@ -3035,9 +3034,6 @@ static void scrub_parity_check_and_repair(struct scrub_parity *sparity)
if (!rbio)
goto rbio_out;
- list_for_each_entry(spage, &sparity->spages, list)
- raid56_add_scrub_pages(rbio, spage->page, spage->logical);
-
scrub_pending_bio_inc(sctx);
raid56_parity_submit_scrub_rbio(rbio);
return;
--
2.12.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v4 4/5] btrfs: Wait flighting bio before freeing target device for raid56
2017-03-30 6:32 [PATCH v4 0/5] raid56: scrub related fixes Qu Wenruo
` (2 preceding siblings ...)
2017-03-30 6:32 ` [PATCH v4 3/5] btrfs: scrub: Don't append on-disk pages for raid56 scrub Qu Wenruo
@ 2017-03-30 6:32 ` Qu Wenruo
2017-03-30 6:32 ` [PATCH v4 5/5] btrfs: Prevent scrub recheck from racing with dev replace Qu Wenruo
4 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2017-03-30 6:32 UTC (permalink / raw)
To: linux-btrfs; +Cc: bo.li.liu
When raid56 dev replace is cancelled by running scrub, we will free target
device without waiting flighting bios, causing the following NULL
pointer deference or general protection.
BUG: unable to handle kernel NULL pointer dereference at 00000000000005e0
IP: generic_make_request_checks+0x4d/0x610
CPU: 1 PID: 11676 Comm: kworker/u4:14 Tainted: G O 4.11.0-rc2 #72
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
Workqueue: btrfs-endio-raid56 btrfs_endio_raid56_helper [btrfs]
task: ffff88002875b4c0 task.stack: ffffc90001334000
RIP: 0010:generic_make_request_checks+0x4d/0x610
Call Trace:
? generic_make_request+0xc7/0x360
generic_make_request+0x24/0x360
? generic_make_request+0xc7/0x360
submit_bio+0x64/0x120
? page_in_rbio+0x4d/0x80 [btrfs]
? rbio_orig_end_io+0x80/0x80 [btrfs]
finish_rmw+0x3f4/0x540 [btrfs]
validate_rbio_for_rmw+0x36/0x40 [btrfs]
raid_rmw_end_io+0x7a/0x90 [btrfs]
bio_endio+0x56/0x60
end_workqueue_fn+0x3c/0x40 [btrfs]
btrfs_scrubparity_helper+0xef/0x620 [btrfs]
btrfs_endio_raid56_helper+0xe/0x10 [btrfs]
process_one_work+0x2af/0x720
? process_one_work+0x22b/0x720
worker_thread+0x4b/0x4f0
kthread+0x10f/0x150
? process_one_work+0x720/0x720
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x2e/0x40
RIP: generic_make_request_checks+0x4d/0x610 RSP: ffffc90001337bb8
In btrfs_dev_replace_finishing(), we will call
btrfs_rm_dev_replace_blocked() to wait bios before destroying the target
device when scrub is finished normally.
However when dev replace is aborted, either due to error or canceled by
scrub, we didn't wait bios, this can leads to use-after-free if there
are bios holding the target device.
Furthermore, for raid56 scrub, at least 2 places are calling
btrfs_map_sblock() without protection of bio_counter, leading to the
problem.
This patch fixes the problem by
1) Wait bio_counter before freeing target device when canceling replace
2) When calling btrfs_map_sblock() for raid56, use bio_counter to
protect the call.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
---
fs/btrfs/dev-replace.c | 2 ++
fs/btrfs/raid56.c | 14 ++++++++++++++
fs/btrfs/scrub.c | 5 +++++
3 files changed, 21 insertions(+)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index e653921f05d9..b9d88136b5a9 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -546,8 +546,10 @@ static int btrfs_dev_replace_finishing(struct btrfs_fs_info *fs_info,
mutex_unlock(&fs_info->chunk_mutex);
mutex_unlock(&fs_info->fs_devices->device_list_mutex);
mutex_unlock(&uuid_mutex);
+ btrfs_rm_dev_replace_blocked(fs_info);
if (tgt_device)
btrfs_destroy_dev_replace_tgtdev(fs_info, tgt_device);
+ btrfs_rm_dev_replace_unblocked(fs_info);
mutex_unlock(&dev_replace->lock_finishing_cancel_unmount);
return scrub_ret;
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 1571bf26dc07..5c180fea32ab 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -2194,6 +2194,8 @@ static void read_rebuild_work(struct btrfs_work *work)
/*
* The following code is used to scrub/replace the parity stripe
*
+ * Caller must have already increased bio_counter for getting @bbio.
+ *
* Note: We need make sure all the pages that add into the scrub/replace
* raid bio are correct and not be changed during the scrub/replace. That
* is those pages just hold metadata or file data with checksum.
@@ -2231,6 +2233,12 @@ raid56_parity_alloc_scrub_rbio(struct btrfs_fs_info *fs_info, struct bio *bio,
ASSERT(rbio->stripe_npages == stripe_nsectors);
bitmap_copy(rbio->dbitmap, dbitmap, stripe_nsectors);
+ /*
+ * We have already increased bio_counter when getting bbio, record it
+ * so we can free it at rbio_orig_end_io().
+ */
+ rbio->generic_bio_cnt = 1;
+
return rbio;
}
@@ -2673,6 +2681,12 @@ raid56_alloc_missing_rbio(struct btrfs_fs_info *fs_info, struct bio *bio,
return NULL;
}
+ /*
+ * When we get bbio, we have already increased bio_counter, record it
+ * so we can free it at rbio_orig_end_io()
+ */
+ rbio->generic_bio_cnt = 1;
+
return rbio;
}
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index bffbe3ce7d70..5720ecdad5d7 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2427,6 +2427,7 @@ static void scrub_missing_raid56_pages(struct scrub_block *sblock)
int ret;
int i;
+ btrfs_bio_counter_inc_blocked(fs_info);
ret = btrfs_map_sblock(fs_info, BTRFS_MAP_GET_READ_MIRRORS, logical,
&length, &bbio, 0, 1);
if (ret || !bbio || !bbio->raid_map)
@@ -2471,6 +2472,7 @@ static void scrub_missing_raid56_pages(struct scrub_block *sblock)
rbio_out:
bio_put(bio);
bbio_out:
+ btrfs_bio_counter_dec(fs_info);
btrfs_put_bbio(bbio);
spin_lock(&sctx->stat_lock);
sctx->stat.malloc_errors++;
@@ -3014,6 +3016,8 @@ static void scrub_parity_check_and_repair(struct scrub_parity *sparity)
goto out;
length = sparity->logic_end - sparity->logic_start;
+
+ btrfs_bio_counter_inc_blocked(fs_info);
ret = btrfs_map_sblock(fs_info, BTRFS_MAP_WRITE, sparity->logic_start,
&length, &bbio, 0, 1);
if (ret || !bbio || !bbio->raid_map)
@@ -3041,6 +3045,7 @@ static void scrub_parity_check_and_repair(struct scrub_parity *sparity)
rbio_out:
bio_put(bio);
bbio_out:
+ btrfs_bio_counter_dec(fs_info);
btrfs_put_bbio(bbio);
bitmap_or(sparity->ebitmap, sparity->ebitmap, sparity->dbitmap,
sparity->nsectors);
--
2.12.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 5/5] btrfs: Prevent scrub recheck from racing with dev replace
2017-03-30 6:32 [PATCH v4 0/5] raid56: scrub related fixes Qu Wenruo
` (3 preceding siblings ...)
2017-03-30 6:32 ` [PATCH v4 4/5] btrfs: Wait flighting bio before freeing target device for raid56 Qu Wenruo
@ 2017-03-30 6:32 ` Qu Wenruo
4 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2017-03-30 6:32 UTC (permalink / raw)
To: linux-btrfs; +Cc: bo.li.liu
scrub_setup_recheck_block() calls btrfs_map_sblock() and then accesses
bbio without protection of bio_counter.
This can lead to use-after-free if racing with dev replace cancel.
Fix it by increasing bio_counter before calling btrfs_map_sblock() and
decreasing the bio_counter when corresponding recover is finished.
Reported-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
---
fs/btrfs/scrub.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 5720ecdad5d7..928db379a09b 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1077,9 +1077,11 @@ static inline void scrub_get_recover(struct scrub_recover *recover)
atomic_inc(&recover->refs);
}
-static inline void scrub_put_recover(struct scrub_recover *recover)
+static inline void scrub_put_recover(struct btrfs_fs_info *fs_info,
+ struct scrub_recover *recover)
{
if (atomic_dec_and_test(&recover->refs)) {
+ btrfs_bio_counter_dec(fs_info);
btrfs_put_bbio(recover->bbio);
kfree(recover);
}
@@ -1478,7 +1480,7 @@ static int scrub_handle_errored_block(struct scrub_block *sblock_to_check)
sblock->pagev[page_index]->sblock = NULL;
recover = sblock->pagev[page_index]->recover;
if (recover) {
- scrub_put_recover(recover);
+ scrub_put_recover(fs_info, recover);
sblock->pagev[page_index]->recover =
NULL;
}
@@ -1570,16 +1572,19 @@ static int scrub_setup_recheck_block(struct scrub_block *original_sblock,
* with a length of PAGE_SIZE, each returned stripe
* represents one mirror
*/
+ btrfs_bio_counter_inc_blocked(fs_info);
ret = btrfs_map_sblock(fs_info, BTRFS_MAP_GET_READ_MIRRORS,
logical, &mapped_length, &bbio, 0, 1);
if (ret || !bbio || mapped_length < sublen) {
btrfs_put_bbio(bbio);
+ btrfs_bio_counter_dec(fs_info);
return -EIO;
}
recover = kzalloc(sizeof(struct scrub_recover), GFP_NOFS);
if (!recover) {
btrfs_put_bbio(bbio);
+ btrfs_bio_counter_dec(fs_info);
return -ENOMEM;
}
@@ -1605,7 +1610,7 @@ static int scrub_setup_recheck_block(struct scrub_block *original_sblock,
spin_lock(&sctx->stat_lock);
sctx->stat.malloc_errors++;
spin_unlock(&sctx->stat_lock);
- scrub_put_recover(recover);
+ scrub_put_recover(fs_info, recover);
return -ENOMEM;
}
scrub_page_get(page);
@@ -1647,7 +1652,7 @@ static int scrub_setup_recheck_block(struct scrub_block *original_sblock,
scrub_get_recover(recover);
page->recover = recover;
}
- scrub_put_recover(recover);
+ scrub_put_recover(fs_info, recover);
length -= sublen;
logical += sublen;
page_index++;
--
2.12.1
^ permalink raw reply related [flat|nested] 13+ messages in thread