public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-mtd@lists.infradead.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	Mark Vasut <marek.vasut@gmail.com>,
	Boris BREZILLON <boris.brezillon@free-electrons.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	tharvey@gateworks.com, stable <stable@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [PATCH] ubi: Reject MLC NAND
Date: Thu, 08 Mar 2018 15:43:12 +0100	[thread overview]
Message-ID: <3797589.z8fAhu5iDP@blindfold> (raw)
In-Reply-To: <CACRpkdYOqt4xTqGmbSwd_R84NRD8GA9TsHEk_hJ68hhxwbsL_Q@mail.gmail.com>

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

  reply	other threads:[~2018-03-08 14:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-03 10:45 [PATCH] ubi: Reject MLC NAND Richard Weinberger
2018-03-04 19:46 ` Boris Brezillon
2018-03-06 23:18 ` Pavel Machek
2018-03-07  1:57   ` David Oberhollenzer
2018-03-07  8:01   ` Richard Weinberger
2018-03-07 15:24     ` Artem Bityutskiy
2018-03-07 21:43     ` Pavel Machek
2018-03-07 22:08       ` Steve deRosier
2018-03-07 22:11         ` David Woodhouse
2018-03-07 22:17           ` Pavel Machek
2018-03-07 22:30             ` Boris Brezillon
2018-03-07 23:27               ` Willy Tarreau
2018-03-07 22:40       ` Boris Brezillon
2018-03-08 13:42 ` Linus Walleij
2018-03-08 14:43   ` Richard Weinberger [this message]
2018-03-08 15:01     ` Artem Bityutskiy
2018-03-08 15:28       ` Richard Weinberger
2018-03-08 15:34         ` Artem Bityutskiy

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=3797589.z8fAhu5iDP@blindfold \
    --to=richard@nod.at \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    --cc=ulf.hansson@linaro.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