mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Stefan Riedmueller <s.riedmueller@phytec.de>
To: barebox@lists.infradead.org
Subject: [PATCH v2] mtd: ubi: Max out wear-leveling threshold
Date: Fri, 20 Sep 2019 13:35:19 +0200	[thread overview]
Message-ID: <1568979319-254499-1-git-send-email-s.riedmueller@phytec.de> (raw)

Due to the recursive ubi_thread implementation in the barebox, a large
amount of wear-leveling can lead to a stack overflow.

This was observed during extensive ubi stress tests with the linux
kernel and periodic power cycles. We found that if the wear-leveling
threshold is exceeded and a large amount of erase blocks need
wear-leveling the stack can overflow.

The hardware used to observe this was a phyCORE-i.MX 6 with 1GB NAND flash.

As the kernel is perfectly capable of handling wear-leveling we can
disable wear-leveling in the barebox by maxing out the threshold and
removing its Kconfig option.

Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Changes in v2:
 - Remove threshold config completely instead of just maxing out the default
---
 drivers/mtd/ubi/Kconfig | 17 -----------------
 drivers/mtd/ubi/build.c |  2 +-
 drivers/mtd/ubi/ubi.h   | 11 +++++++++++
 drivers/mtd/ubi/wl.c    |  8 --------
 4 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 9a344082b7bb..ed2f13d14c30 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -10,23 +10,6 @@ menuconfig MTD_UBI
 
 if MTD_UBI
 
-config MTD_UBI_WL_THRESHOLD
-	int "UBI wear-leveling threshold"
-	default 4096
-	range 2 65536
-	help
-	  This parameter defines the maximum difference between the highest
-	  erase counter value and the lowest erase counter value of eraseblocks
-	  of UBI devices. When this threshold is exceeded, UBI starts performing
-	  wear leveling by means of moving data from eraseblock with low erase
-	  counter to eraseblocks with high erase counter.
-
-	  The default value should be OK for SLC NAND flashes, NOR flashes and
-	  other flashes which have eraseblock life-cycle 100000 or more.
-	  However, in case of MLC NAND flashes which typically have eraseblock
-	  life-cycle less than 10000, the threshold should be lessened (e.g.,
-	  to 128 or 256, although it does not have to be power of 2).
-
 config MTD_UBI_BEB_LIMIT
 	int "Maximum expected bad eraseblock count per 1024 eraseblocks"
 	default 20
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 493c778c3fdb..604fe87e53b6 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -655,7 +655,7 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
 		ubi->vol_count - UBI_INT_VOL_COUNT, UBI_INT_VOL_COUNT,
 		ubi->vtbl_slots);
 	ubi_msg(ubi, "max/mean erase counter: %d/%d, WL threshold: %d, image sequence number: %u",
-		ubi->max_ec, ubi->mean_ec, CONFIG_MTD_UBI_WL_THRESHOLD,
+		ubi->max_ec, ubi->mean_ec, UBI_WL_THRESHOLD,
 		ubi->image_seq);
 	ubi_msg(ubi, "available PEBs: %d, total reserved PEBs: %d, PEBs reserved for bad PEB handling: %d",
 		ubi->avail_pebs, ubi->rsvd_pebs, ubi->beb_rsvd_pebs);
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 922c1a3c8b49..7d07bbf19720 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -69,6 +69,17 @@
  */
 #define UBI_PROT_QUEUE_LEN 10
 
+/*
+ * Maximum difference between two erase counters. If this threshold is
+ * exceeded, the WL sub-system starts moving data from used physical
+ * eraseblocks with low erase counter to free physical eraseblocks with high
+ * erase counter.
+ * Extensive wear-leveling in the barebox can lead to stack overflows. Thus
+ * disable it by setting the threshold to the OS's max configurable value and
+ * leave wear-leveling to the OS.
+ */
+#define UBI_WL_THRESHOLD 65536
+
 /* The volume ID/LEB number/erase counter is unknown */
 #define UBI_UNKNOWN -1
 
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index cf90ecfb2385..013ba3e1ffc7 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -101,14 +101,6 @@
 #define WL_RESERVED_PEBS 1
 
 /*
- * Maximum difference between two erase counters. If this threshold is
- * exceeded, the WL sub-system starts moving data from used physical
- * eraseblocks with low erase counter to free physical eraseblocks with high
- * erase counter.
- */
-#define UBI_WL_THRESHOLD CONFIG_MTD_UBI_WL_THRESHOLD
-
-/*
  * When a physical eraseblock is moved, the WL sub-system has to pick the target
  * physical eraseblock to move to. The simplest way would be just to pick the
  * one with the highest erase counter. But in certain workloads this could lead
-- 
2.7.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2019-09-20 11:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 11:35 Stefan Riedmueller [this message]
2019-09-23  6:53 ` Sascha Hauer

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=1568979319-254499-1-git-send-email-s.riedmueller@phytec.de \
    --to=s.riedmueller@phytec.de \
    --cc=barebox@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox