All of lore.kernel.org
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: linux-bcache@vger.kernel.org
Cc: linux-block@vger.kernel.org, hare@suse.de, Coly Li <colyli@suse.de>
Subject: [PATCH v4 04/16] bcache: fix super block seq numbers comparision in register_cache_set()
Date: Fri, 17 Jul 2020 19:22:24 +0800	[thread overview]
Message-ID: <20200717112236.44761-5-colyli@suse.de> (raw)
In-Reply-To: <20200717112236.44761-1-colyli@suse.de>

In register_cache_set(), c is pointer to struct cache_set, and ca is
pointer to struct cache, if ca->sb.seq > c->sb.seq, it means this
registering cache has up to date version and other members, the in-
memory version and other members should be updated to the newer value.

But current implementation makes a cache set only has a single cache
device, so the above assumption works well except for a special case.
The execption is when a cache device new created and both ca->sb.seq and
c->sb.seq are 0, because the super block is never flushed out yet. In
the location for the following if() check,
2156         if (ca->sb.seq > c->sb.seq) {
2157                 c->sb.version           = ca->sb.version;
2158                 memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16);
2159                 c->sb.flags             = ca->sb.flags;
2160                 c->sb.seq               = ca->sb.seq;
2161                 pr_debug("set version = %llu\n", c->sb.version);
2162         }
c->sb.version is not initialized yet and valued 0. When ca->sb.seq is 0,
the if() check will fail (because both values are 0), and the cache set
version, set_uuid, flags and seq won't be updated.

The above problem is hiden for current code, because the bucket size is
compatible among different super block version. And the next time when
running cache set again, ca->sb.seq will be larger than 0 and cache set
super block version will be updated properly.

But if the large bucket feature is enabled,  sb->bucket_size is the low
16bits of the bucket size. For a power of 2 value, when the actual
bucket size exceeds 16bit width, sb->bucket_size will always be 0. Then
read_super_common() will fail because the if() check to
is_power_of_2(sb->bucket_size) is false. This is how the long time
hidden bug is triggered.

This patch modifies the if() check to the following way,
2156         if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) {
Then cache set's version, set_uuid, flags and seq will always be updated
corectly including for a new created cache device.

Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
---
 drivers/md/bcache/super.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 7ad6bbabfc66..d5ed8f31e123 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2146,7 +2146,14 @@ static const char *register_cache_set(struct cache *ca)
 	    sysfs_create_link(&c->kobj, &ca->kobj, buf))
 		goto err;
 
-	if (ca->sb.seq > c->sb.seq) {
+	/*
+	 * A special case is both ca->sb.seq and c->sb.seq are 0,
+	 * such condition happens on a new created cache device whose
+	 * super block is never flushed yet. In this case c->sb.version
+	 * and other members should be updated too, otherwise we will
+	 * have a mistaken super block version in cache set.
+	 */
+	if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) {
 		c->sb.version		= ca->sb.version;
 		memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16);
 		c->sb.flags             = ca->sb.flags;
-- 
2.26.2


  parent reply	other threads:[~2020-07-17 11:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 11:22 [PATCH v4 00/16] bcache: extend bucket size to 32bit width Coly Li
2020-07-17 11:22 ` [PATCH v4 01/16] bcache: add read_super_common() to read major part of super block Coly Li
2020-07-17 11:22 ` [PATCH v4 02/16] bcache: add more accurate error information in read_super_common() Coly Li
2020-07-17 11:22 ` [PATCH v4 03/16] bcache: disassemble the big if() checks in bch_cache_set_alloc() Coly Li
2020-07-17 11:22 ` Coly Li [this message]
2020-07-17 11:22 ` [PATCH v4 05/16] bcache: increase super block version for cache device and backing device Coly Li
2020-07-17 11:22 ` [PATCH v4 06/16] bcache: move bucket related code into read_super_common() Coly Li
2020-07-17 11:22 ` [PATCH v4 07/16] bcache: struct cache_sb is only for in-memory super block now Coly Li
2020-07-17 11:22 ` [PATCH v4 08/16] bcache: introduce meta_bucket_pages() related helper routines Coly Li
2020-07-17 11:22 ` [PATCH v4 09/16] bcache: handle c->uuids properly for bucket size > 8MB Coly Li
2020-07-17 11:22 ` [PATCH v4 10/16] bcache: handle cache prio_buckets and disk_buckets " Coly Li
2020-07-17 11:22 ` [PATCH v4 11/16] bcache: handle cache set verify_ondisk " Coly Li
2020-07-17 11:22 ` [PATCH v4 12/16] bcache: handle btree node memory allocation " Coly Li
2020-07-17 11:22 ` [PATCH v4 13/16] bcache: add bucket_size_hi into struct cache_sb_disk for large bucket Coly Li
2020-07-17 11:22 ` [PATCH v4 14/16] bcache: add sysfs file to display feature sets information of cache set Coly Li
2020-07-17 11:22 ` [PATCH v4 15/16] bcache: avoid extra memory allocation from mempool c->fill_iter Coly Li
2020-07-17 11:22 ` [PATCH v4 16/16] bcache: avoid extra memory consumption in struct bbio for large bucket size Coly Li

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=20200717112236.44761-5-colyli@suse.de \
    --to=colyli@suse.de \
    --cc=hare@suse.de \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@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.