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, Coly Li <colyli@suse.de>
Subject: [RFC PATCH 12/16] bcache: handle cache set verify_ondisk properly for bucket size > 8MB
Date: Sun,  5 Jul 2020 23:55:57 +0800	[thread overview]
Message-ID: <20200705155601.5404-13-colyli@suse.de> (raw)
In-Reply-To: <20200705155601.5404-1-colyli@suse.de>

In bch_btree_cache_alloc() when CONFIG_BCACHE_DEBUG is configured,
allocate memory for c->verify_ondisk may fail if the bucket size > 8MB,
which will require __get_free_pages() to allocate continuous pages
with order > 11 (the default MAX_ORDER of Linux buddy allocator). Such
over size allocation will fail, and cause 2 problems,
- When CONFIG_BCACHE_DEBUG is configured,  bch_btree_verify() does not
  work, because c->verify_ondisk is NULL and bch_btree_verify() returns
  immediately.
- bch_btree_cache_alloc() will fail due to c->verify_ondisk allocation
  failed, then the whole cache device registration fails. And because of
  this failure, the first problem of bch_btree_verify() has no chance to
  be triggered.

This patch fixes the above problem by two means,
1) If pages allocation of c->verify_ondisk fails, set it to NULL and
   returns bch_btree_cache_alloc() with -ENOMEM.
2) When calling __get_free_pages() to allocate c->verify_ondisk pages,
   use ilog2(meta_bucket_pages(&c->sb)) to make sure ilog2() will always
   generate a pages order <= MAX_ORDER (or CONFIG_FORCE_MAX_ZONEORDER).
   Then the buddy system won't directly reject the allocation request.

Signed-off-by: Coly Li <colyli@suse.de>
---
 drivers/md/bcache/btree.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 6548a601edf0..a9d59b6c7d85 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -738,7 +738,7 @@ void bch_btree_cache_free(struct cache_set *c)
 	if (c->verify_data)
 		list_move(&c->verify_data->list, &c->btree_cache);
 
-	free_pages((unsigned long) c->verify_ondisk, ilog2(bucket_pages(c)));
+	free_pages((unsigned long) c->verify_ondisk, ilog2(meta_bucket_pages(&c->sb)));
 #endif
 
 	list_splice(&c->btree_cache_freeable,
@@ -785,7 +785,15 @@ int bch_btree_cache_alloc(struct cache_set *c)
 	mutex_init(&c->verify_lock);
 
 	c->verify_ondisk = (void *)
-		__get_free_pages(GFP_KERNEL, ilog2(bucket_pages(c)));
+		__get_free_pages(GFP_KERNEL, ilog2(meta_bucket_pages(&c->sb)));
+	if (!c->verify_ondisk) {
+		/*
+		 * Don't worry about the mca_rereserve buckets
+		 * allocated in previous for-loop, they will be
+		 * handled properly in bch_cache_set_unregister().
+		 */
+		return -ENOMEM;
+	}
 
 	c->verify_data = mca_bucket_alloc(c, &ZERO_KEY, GFP_KERNEL);
 
-- 
2.26.2


  parent reply	other threads:[~2020-07-05 15:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05 15:55 [RFC PATCH 00/16] bcache: extend bucket size to 32bit width Coly Li
2020-07-05 15:55 ` [RFC PATCH 01/16] bcache: add comments to mark member offset of struct cache_sb_disk Coly Li
2020-07-05 15:55 ` [RFC PATCH 02/16] bcache: add read_super_basic() to read major part of super block Coly Li
2020-07-05 15:55 ` [RFC PATCH 03/16] bcache: add more accurate error information in read_super_basic() Coly Li
2020-07-05 15:55 ` [RFC PATCH 04/16] bcache: disassemble the big if() checks in bch_cache_set_alloc() Coly Li
2020-07-05 15:55 ` [RFC PATCH 05/16] bcache: fix super block seq numbers comparision in register_cache_set() Coly Li
2020-07-05 15:55 ` [RFC PATCH 06/16] bcache: increase super block version for cache device and backing device Coly Li
2020-07-05 15:55 ` [RFC PATCH 07/16] bcache: move bucket related code into read_super_basic() Coly Li
2020-07-05 15:55 ` [RFC PATCH 08/16] bcache: struct cache_sb is only for in-memory super block now Coly Li
2020-07-05 15:55 ` [RFC PATCH 09/16] bcache: introduce meta_bucket_pages() related helper routines Coly Li
2020-07-05 15:55 ` [RFC PATCH 10/16] bcache: handle c->uuids properly for bucket size > 8MB Coly Li
2020-07-05 15:55 ` [RFC PATCH 11/16] bcache: handle cache prio_buckets and disk_buckets " Coly Li
2020-07-05 15:55 ` Coly Li [this message]
2020-07-05 15:55 ` [RFC PATCH 13/16] bcache: handle btree node memory allocation " Coly Li
2020-07-05 15:55 ` [RFC PATCH 14/16] bcache: add bucket_size_hi into struct cache_sb_disk for large bucket Coly Li
2020-07-05 15:56 ` [RFC PATCH 15/16] bcache: avoid extra memory allocation from mempool c->fill_iter Coly Li
2020-07-05 15:56 ` [RFC PATCH 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=20200705155601.5404-13-colyli@suse.de \
    --to=colyli@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.