Received: by 10.223.185.116 with SMTP id b49csp6388775wrg; Thu, 8 Mar 2018 06:43:34 -0800 (PST) X-Google-Smtp-Source: AG47ELsHSpoxnSi3KRIh0sa/bUH6RIr/2Pw9rGP1JytV+hruaNqH/JQHGkDFBZ62P9TtFEDBBF0I X-Received: by 10.99.55.11 with SMTP id e11mr21358323pga.237.1520520214282; Thu, 08 Mar 2018 06:43:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520520214; cv=none; d=google.com; s=arc-20160816; b=qCq9skodHn0nmxjpAsrG01a/YNrfR9eI0pTh8siJ4lvsij9Sz8wCqQcqtBtBn22KrI zo6sGVNlPj+z5TMP5r2SNEIiYp2umsP8/i6Amiqdr+ALlQ1M52ErSVfAaR9c9QQgBdvI wxAs64W0CzE/xzEHoNYgvow/VA5zG+Z53IrFVyb9uocfpeTjiXnWJKPln6/4evoV5v9T F2x0bjgJZ4I4hwDwYhgl/IKjOQqzuqxgtZui+NnfXXD8Ebp/2b7n0rqIzCgdttiE+GMd Pqdbqp0RgM+y/1kJfmeli1LIUsjvmDTtB3FPoFmO++MZ9tT0jZ/uhB5alTuc4VttEhx7 Mlcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=DWHeKSASfwxiJYBWbdpcTJ2AHb1kpsbjEWXLdo4lay4=; b=Jt5+0WzVlT61wZicTpUEk2vutc10GOXvZZTL1tCcwVnl1BAafN97xaLtly+vNEnt83 F2zvduiWND2mjkAfqcD2aD5iCam1bmO9gsO1R6UReALiCpRMHdtXHphF123rDFNZP/Nz xJolniWU0fAWo7vo9/oayYVF+zS38PeSe62F80vXnbE/eA79J6TCtcwoC9myqSHHARFJ eKiIlAKpdSjDzR+ESeYmPEUuHpGtNuhHJqeoDOcd7fMzGWOI2lPNL9O9vdzGniAmXDFE npRoGpm3gTpyRO4ZcQjUcBMk9CD+Huu8ywOHpyfPV44mw7E1nBUo9YNE6SZ9sZMPbIRo Zbvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64-v6si15122265ply.209.2018.03.08.06.43.17; Thu, 08 Mar 2018 06:43:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933478AbeCHOlo convert rfc822-to-8bit (ORCPT + 99 others); Thu, 8 Mar 2018 09:41:44 -0500 Received: from lilium.sigma-star.at ([109.75.188.150]:47740 "EHLO lilium.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009AbeCHOln (ORCPT ); Thu, 8 Mar 2018 09:41:43 -0500 Received: from localhost (localhost [127.0.0.1]) by lilium.sigma-star.at (Postfix) with ESMTP id 57667181A43EF; Thu, 8 Mar 2018 15:41:41 +0100 (CET) From: Richard Weinberger To: Linus Walleij Cc: linux-mtd@lists.infradead.org, "linux-kernel@vger.kernel.org" , Cyrille Pitchen , Mark Vasut , Boris BREZILLON , Brian Norris , David Woodhouse , Artem Bityutskiy , tharvey@gateworks.com, stable , Ulf Hansson Subject: Re: [PATCH] ubi: Reject MLC NAND Date: Thu, 08 Mar 2018 15:43:12 +0100 Message-ID: <3797589.z8fAhu5iDP@blindfold> In-Reply-To: References: <20180303104554.5958-1-richard@nod.at> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > 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