While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb. In order to protect users from bad surprises, refuse to attach to MLC NAND.
Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger richard@nod.at --- drivers/mtd/ubi/build.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index e941395de3ae..753494e042d5 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, return -EINVAL; }
+ /* + * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes. + * MLC NAND is different and needs special care, otherwise UBI or UBIFS + * will die soon and you will lose all your data. + */ + if (mtd->type == MTD_MLCNANDFLASH) { + pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n", + mtd->index); + return -EINVAL; + } + if (ubi_num == UBI_DEV_NUM_AUTO) { /* Search for an empty slot in the @ubi_devices array */ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
On Sat, 3 Mar 2018 11:45:54 +0100 Richard Weinberger richard@nod.at wrote:
While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb. In order to protect users from bad surprises, refuse to attach to MLC NAND.
Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger richard@nod.at
Acked-by: Boris Brezillon boris.brezillon@bootlin.com
drivers/mtd/ubi/build.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index e941395de3ae..753494e042d5 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, return -EINVAL; }
- /*
* Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.* MLC NAND is different and needs special care, otherwise UBI or UBIFS* will die soon and you will lose all your data.*/- if (mtd->type == MTD_MLCNANDFLASH) {
pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",mtd->index);return -EINVAL;- }
- if (ubi_num == UBI_DEV_NUM_AUTO) { /* Search for an empty slot in the @ubi_devices array */ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
On Sat, Mar 3, 2018 at 11:45 AM, Richard Weinberger richard@nod.at wrote:
While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb.
In order to protect users from bad surprises, refuse to attach to MLC NAND.
Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger richard@nod.at
I'm sorry to disturb in this interesting discussion about what "stable" really means as in "stable kernel". Stable for who and in what sense, that seems to be the question.
But my main problem here is to understand who the consumers of the MLC NAND devices really are.
I hear some talk here about lab boards. But where is this really deployed, large-scale? And who are the people that will have their devices potentially not booting after this patch?
I am pretty sure these people are board support or customization consultants with work being done for some certain products, and not hobbyists and even less end consumers, right?
What kind of devices are MLC NANDs being deployed in? Certainly not laptops, tablets and phones, they all use eMMC and even start to venture into UFS (unified flash storage).
What is using these flashes? Routers and switches? NAS boxes? Industrial control? Automotive?
Or are (God forbid, but would not surprise me) talking about a Linux instance running inside of eMMCs or UFS devices?
Yours, Linus Walleij
Linus,
Am Donnerstag, 8. März 2018, 14:42:16 CET schrieb Linus Walleij:
On Sat, Mar 3, 2018 at 11:45 AM, Richard Weinberger richard@nod.at wrote:
While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb.
In order to protect users from bad surprises, refuse to attach to MLC NAND.
Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger richard@nod.at
I'm sorry to disturb in this interesting discussion about what "stable" really means as in "stable kernel". Stable for who and in what sense, that seems to be the question.
But my main problem here is to understand who the consumers of the MLC NAND devices really are.
I hear some talk here about lab boards. But where is this really deployed, large-scale? And who are the people that will have their devices potentially not booting after this patch?
I am pretty sure these people are board support or customization consultants with work being done for some certain products, and not hobbyists and even less end consumers, right?
Correct. I saw vendor specific kernels that have hardware and software hacks to make UBI on MLC NAND somehow work. Somehow in terms of, the filesystem will die just a little later.
But these people do _not_ run a vanilla (stable) kernel. We support mainline, nothing more, nothing less.
What kind of devices are MLC NANDs being deployed in? Certainly not laptops, tablets and phones, they all use eMMC and even start to venture into UFS (unified flash storage).
What is using these flashes? Routers and switches? NAS boxes? Industrial control? Automotive?
Or are (God forbid, but would not surprise me) talking about a Linux instance running inside of eMMCs or UFS devices?
We need to clarify that even more. Upstream UBI and UBIFS cannot work with MLC NAND correctly. Any such product would die within days... I have many MLC boards on my desk, by running a mainline kernel on them, I can kill every single one within a few minutes, either by plugging the power or triggering read-disturb.
As stated by David Woodhouse, it was a huge mistake by UBI to not reject MLC NAND from the very beginning. The sole purpose of this patch is fixing that mistake and make it very clear.
Thanks, //richard
On Thu, 2018-03-08 at 15:43 +0100, Richard Weinberger wrote:
As stated by David Woodhouse, it was a huge mistake by UBI to not reject MLC NAND from the very beginning.
Correction: when we were developing UBI/UBIFS and upstreamed them, MLC was widely used yet we did not really know about it. So there was nothing to reject yet.
The mistake is that we did not add the reject timely. When people started reporting MLC issues we were answering that UBI/UBIFS stack needs more work to make MLC safe to use, and we hoped someone would do the work.
Artem.
Artem,
Am Donnerstag, 8. März 2018, 16:01:15 CET schrieb Artem Bityutskiy:
On Thu, 2018-03-08 at 15:43 +0100, Richard Weinberger wrote:
As stated by David Woodhouse, it was a huge mistake by UBI to not reject MLC NAND from the very beginning.
Correction: when we were developing UBI/UBIFS and upstreamed them, MLC was widely used yet we did not really know about it. So there was nothing to reject yet.
You mean *not* widely used?
The mistake is that we did not add the reject timely. When people started reporting MLC issues we were answering that UBI/UBIFS stack needs more work to make MLC safe to use, and we hoped someone would do the work.
True. TBH Boris and I also thought that adding MLC support is not a that big deal...
Thanks, //richard
linux-stable-mirror@lists.linaro.org
-
Artem Bityutskiy -
Boris Brezillon -
Linus Walleij -
Richard Weinberger