linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1] second wave bcache fixes for Linux v4.21
@ 2018-12-26  5:04 Coly Li
  2018-12-26  5:04 ` [PATCH 1/1] bcache: treat stale && dirty keys as bad keys Coly Li
  0 siblings, 1 reply; 2+ messages in thread
From: Coly Li @ 2018-12-26  5:04 UTC (permalink / raw)
  To: axboe; +Cc: linux-bcache, linux-block, Coly Li

Hi Jens,

We have one more patch, which is a fix to avoid unnecessary bogus
failure on staled and dirty btree key of bcache.

This bogus failure does not always happen, but when it happens,
bcache code will take it as critical failure and call
bch_cache_set_error(), which may stop the cache set and bcache device.
If bcache is set to panic on error, this bogus failure can panic the
kernel too. Indeed a staled and dirty key may exist and we can just
report it as a bad key, it is unncessary to panic the whole kernel or
stop the cache set.

Therefore IMHO this is an important fix, we should have it in
Linux v4.21.

Thanks in advance.

Coly Li
---
Tang Junhui (1):
  bcache: treat stale && dirty keys as bad keys

 drivers/md/bcache/extents.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

-- 
2.16.4


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [PATCH 1/1] bcache: treat stale && dirty keys as bad keys
  2018-12-26  5:04 [PATCH 0/1] second wave bcache fixes for Linux v4.21 Coly Li
@ 2018-12-26  5:04 ` Coly Li
  0 siblings, 0 replies; 2+ messages in thread
From: Coly Li @ 2018-12-26  5:04 UTC (permalink / raw)
  To: axboe; +Cc: linux-bcache, linux-block, Tang Junhui, stable, Coly Li

From: Tang Junhui <tang.junhui.linux@gmail.com>

Stale && dirty keys can be produced in the follow way:
After writeback in write_dirty_finish(), dirty keys k1 will
replace by clean keys k2
==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key);
==>btree_insert_fn(struct btree_op *b_op, struct btree *b)
==>static int bch_btree_insert_node(struct btree *b,
       struct btree_op *op,
       struct keylist *insert_keys,
       atomic_t *journal_ref,
Then two steps:
A) update k1 to k2 in btree node memory;
   bch_btree_insert_keys(b, op, insert_keys, replace_key)
B) Write the bset(contains k2) to cache disk by a 30s delay work
   bch_btree_leaf_dirty(b, journal_ref).
But before the 30s delay work write the bset to cache device,
these things happened:
A) GC works, and reclaim the bucket k2 point to;
B) Allocator works, and invalidate the bucket k2 point to,
   and increase the gen of the bucket, and place it into free_inc
   fifo;
C) Until now, the 30s delay work still does not finish work,
   so in the disk, the key still is k1, it is dirty and stale
   (its gen is smaller than the gen of the bucket). and then the
   machine power off suddenly happens;
D) When the machine power on again, after the btree reconstruction,
   the stale dirty key appear.

In bch_extent_bad(), when expensive_debug_checks is off, it would
treat the dirty key as good even it is stale keys, and it would
cause bellow probelms:
A) In read_dirty() it would cause machine crash:
   BUG_ON(ptr_stale(dc->disk.c, &w->key, 0));
B) It could be worse when reads hits stale dirty keys, it would
   read old incorrect data.

This patch tolerate the existence of these stale && dirty keys,
and treat them as bad key in bch_extent_bad().

(Coly Li: fix indent format which was modified by sender's email
 client)

Signed-off-by: Tang Junhui <tang.junhui.linux@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Coly Li <colyli@suse.de>
---
 drivers/md/bcache/extents.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/md/bcache/extents.c b/drivers/md/bcache/extents.c
index 956004366699..886710043025 100644
--- a/drivers/md/bcache/extents.c
+++ b/drivers/md/bcache/extents.c
@@ -538,6 +538,7 @@ static bool bch_extent_bad(struct btree_keys *bk, const struct bkey *k)
 {
 	struct btree *b = container_of(bk, struct btree, keys);
 	unsigned int i, stale;
+	char buf[80];
 
 	if (!KEY_PTRS(k) ||
 	    bch_extent_invalid(bk, k))
@@ -547,19 +548,19 @@ static bool bch_extent_bad(struct btree_keys *bk, const struct bkey *k)
 		if (!ptr_available(b->c, k, i))
 			return true;
 
-	if (!expensive_debug_checks(b->c) && KEY_DIRTY(k))
-		return false;
-
 	for (i = 0; i < KEY_PTRS(k); i++) {
 		stale = ptr_stale(b->c, k, i);
 
+		if (stale && KEY_DIRTY(k)) {
+			bch_extent_to_text(buf, sizeof(buf), k);
+			pr_info("stale dirty pointer, stale %u, key: %s",
+				stale, buf);
+		}
+
 		btree_bug_on(stale > BUCKET_GC_GEN_MAX, b,
 			     "key too stale: %i, need_gc %u",
 			     stale, b->c->need_gc);
 
-		btree_bug_on(stale && KEY_DIRTY(k) && KEY_SIZE(k),
-			     b, "stale dirty pointer");
-
 		if (stale)
 			return true;
 
-- 
2.16.4


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-12-26  5:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-26  5:04 [PATCH 0/1] second wave bcache fixes for Linux v4.21 Coly Li
2018-12-26  5:04 ` [PATCH 1/1] bcache: treat stale && dirty keys as bad keys Coly Li

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).