linux-kernel - Re: [RFC][PATCH] UBI: Make MTD_UBI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Mar 2017 19:39:44 +0200
From:   Jesper Nilsson <jesper.nilsson@...s.com>
To:     Marek Vasut <marek.vasut@...il.com>
Cc:     Richard Weinberger <richard@....at>,
        Jesper Nilsson <jespern@...s.com>,
        Artem Bityutskiy <dedekind1@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental


Hi Richard, Marek,

On Thu, Mar 30, 2017 at 12:01:41PM +0200, Marek Vasut wrote:
> On 03/29/2017 10:04 PM, Richard Weinberger wrote:
> > Jesper,
> > 
> > Am 29.03.2017 um 17:38 schrieb Jesper Nilsson:
> >> MTD_UBI_FASTMAP has been set as experimental since it
> >> was merged back in 2012.
> >>
> >> There hasn't been much change in the format,
> >> so we can consider the feature stable and start
> >> being careful about breaking the format.
> >> (This is somewhat of a pre-requisite for anyone actually
> >> using the feature in the real world and depending on it)
> >>
> >> Drop the experimental note and the warning text about
> >> the on-flash format not being finalized.
> > 
> > I fully agree, we can drop this note. But we have to add another
> > one.
> > While Fastmap is a nice feature to speed-up the attach time it
> > comes with a cost. It makes UBI less robust. I saw issues
> > on NAND chips which misbehaved slightly where UBI was able to
> > recover when using a full scan but not when Fastmap was used.
> > The UBI full scan code is paranoid and can sort out problems
> > very early, with Fastmap enabled you lose this valuable property.
> > 
> > So, users should enable Fastmap only when they absolutely need
> > a very fast attach time and be very sure that the NAND works as
> > expected.
> 
> So we should document this with a big fat warning and set fastmap to
> default=n ?

Does this sound reasonable?

Note that this feature makes UBI less robust, since Fastmap does not scan
the full flash, which might lead to problems on misbehaving NAND chips.
Only enable this if the speedup in attach is really important and
you can be sure that the NAND works as expected.


> Best regards,
> Marek Vasut

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@...s.com