My new shiny code for corrupted PEB detection has NOR specific bug.
We tread PEB as corrupted and preserve it, if

1. EC header is OK.
2. VID header is corrupted.
3. data area is not "all 0xFFs"

In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
the headers before erasing the PEB. And we invalidate first the VID
header, and then the EC header. So if a power cut happens after we have
invalidated the VID header, but before we have invalidated the EC
header, we end up with a PEB which satisfies the above 3 conditions,
and the scanning code will treat it as corrupted, and will print
scary warnings, wrongly.

This patch fixes the issue by firt invalidating the EC header, then
invalidating the VID header. In case of power cut inbetween, we still
just lose the EC header, and UBI can deal with this situation gracefully.

Thanks to Anatolij Gustschin <agust@denx.de> for tracking this down.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reported-by: NAnatolij Gustschin <agust@denx.de>
Tested-by: NAnatolij Gustschin <agust@denx.de>

Commit 45aafd32 "UBI: tighten the corrupted PEB criteria"
introduced some return paths that didn't release the ubi->buf_mutex
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

If we get a bit-flip of ECC error while reading the data area, do not add it to
corrupted list, because it is possible that this is just unstable PEB with
corruptions caused by unclean reboots.

This patch also improves commentaries.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

When the data does not contain all 0xFF bytes, 'check_data_ff()' should return
1, not -EINVAL; Also, the caller ('process_eb()') should not add the PEB to the
"corrupted" list if there was a read error.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

While scanning the flash we read all VID headers and store some important
information in 'struct ubi_scan_leb'. Store also the 'copy_flag' value there
as it is needed when comparing LEBs. We do not increase memory consumption
because this is just one bit and we have plenty of spare bits in
'struct ubi_scan_leb' (sizeof(struct ubi_scan_leb) is 48 both with and
without this patch).
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Currently UBI erases all corrupted eraseblocks, irrespectively of the nature
of corruption: corruption due to power cuts and non-power cut corruption.
The former case is OK, but the latter is not, because UBI may destroy
potentially important data.

With this patch, during scanning, when UBI hits a PEB with corrupted VID
header, it checks whether this PEB contains only 0xFF data. If yes, it is
safe to erase this PEB and it is put to the 'erase' list. If not, this may
be important data and it is better to avoid erasing this PEB. Instead,
UBI puts it to the corr list and moves out of the pool of available PEB.
IOW, UBI preserves this PEB.

Such corrupted PEB lessen the amount of available PEBs. So the more of them
we accumulate, the less PEBs are available. The maximum amount of non-power
cut corrupted PEBs is 8.

This patch is a response to UBIFS problem where reporter
(Matthew L. Creech <mlcreech@gmail.com>) observes that UBIFS index points
to an unmapped LEB. The theory is that corresponding PEB somehow got
corrupted and UBI wiped it. This patch (actually a series of patches)
tries to make sure such PEBs are preserved - this would make it is easier
to analyze the corruption.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Start using the 'corr' list and add there PEBs which look truly corrupted,
which means they have corrupted VID header and the data which follows the
corrupted header does not contain all 0xFF bytes.

At the moment, this does not change UBI functionality much because these
PEBs will be erase when scanning finishes. But the plan is to teach UBI
preserving them.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Currently UBI maintains 2 lists of PEBs during scanning:
1. 'erase' list - PEBs which have no corruptions but should be erased
2. 'corr' list - PEBs which have some corruptions and should be erased

But we do not really need 2 lists for PEBs which should be erased after
scanning is done - this is redundant. So this patch makes sure all PEBs
which are corrupted are moved to the head of the 'erase' list. We add
them to the head to make sure they are erased first and we get rid of
corruption ASAP.

However, we do not remove the 'corr' list and realted functions, because
the plan is to use this list for other purposes. Namely, we plan to
put eraseblocks with corruption which does not look like it was caused
by unclean power cut. Then we'll preserve thes PEBs in order to avoid
killing potentially valuable user data.

This patch also amends PEBs accounting, because it was closely tight to
the 'erase'/'corr' lists separation.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch introduces 'add_corrupted()' function and separates out 'corr' list
manipulation from the common 'add_to_list()' function. This is just a
preparation for further changes - this patch does not change functionality.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch improves readability and simplifies scanning code by changing a
long cascade of 'if' statements to a switch statement. This should presumably
be a little faster as well.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Rename local variable 'ec_corr' into 'ec_err' to make the code a little bit
more readable. 'ec_err' is more appropriate because it sounds more like 'error
when EC was read' and it looks more logical because we use it together with
'err'. Just a minor nicification which should improve the rather complex
scanning code.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Currently UBI has one small flaw - when we read EC or VID header, but find only
0xFF bytes, we return UBI_IO_FF and do not report whether we had bit-flips or
not. In case of the VID header, the scanning code adds this PEB to the free list,
even though there were bit-flips.

Imagine the following situation: we start writing VID header to a PEB and have a
power cut, so the PEB becomes unstable. When we scan and read the PEB, we get
a bit-flip. Currently, UBI would just ignore this and treat the PEB as free. This
patch changes UBI behavior and now UBI will schedule this PEB for erasure.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

The 'UBI_IO_PEB_EMPTY' and 'UBI_IO_PEB_FREE' are essentially the same
and mean that there are only 0xFF bytes instead of headers. Simplify
UBI a little by turning them into a single 'UBI_IO_FF' error code.

Also, stop maintaining commentaries in 'ubi_io_read_vid_hdr()' which are
almost identical to commentaries in 'ubi_io_read_ec_hdr()'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Rename UBI_IO_BAD_HDR_READ into UBI_IO_BAD_HDR_EBADMSG which is presumably more
self-documenting and readable. Indeed, the '_READ' suffix does not tell much and
even confuses, while '_EBADMSG' tells about uncorrectable ECC error, because we
use -EBADMSG all over the place to represent ECC errors.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Commit 0798cea8 "UBI: improve corrupted flash handling"
broke delet-compatible volumes handling - it introduced a limit of 8 eraseblocks which
may be corrupted. And delete-compatible eraseblocks are added to the "corrupted" list,
so if we'd have a large delete-compatible volume, UBI would refuse it.

The fix is to add delete-compatible volumes to the erase list instead. Indeed, they are
corrupted, we just have to erase them.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Currently UBI prints

UBI: corrupted PEBs will be formatted

even if there are not corrupted PEBs. Fix this.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

When a delete-compatible volume is found, it is first added to the
'corr' list, which contains "corrupted" PEBs which should be erased,
and then it is added to the used volumes tree. However, the second
step should not be done. This does not cause problems in practice,
because we never access delete-compattible volumes, but it is still
not the right thing to do.

[Artem: amended the commit message and few prints]
Signed-off-by: NBrijesh Singh <brijesh.s.singh@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Fix the followong compilation warnings introduced by commit
095751a6:

drivers/mtd/ubi/scan.c: In function 'check_what_we_have':
drivers/mtd/ubi/scan.c:960: warning: passing argument 1 of 'get_random_bytes' discards qualifiers from pointer target type

Fix the following compilation warnings introduced by commit
1a49af2c:

drivers/mtd/ubi/io.c: In function 'ubi_io_read':
drivers/mtd/ubi/io.c:153: warning: initialization makes integer from pointer without a cast
drivers/mtd/ubi/io.c:170: warning: format '%s' expects type 'char *', but argument 5 has type 'int'
drivers/mtd/ubi/io.c:177: warning: format '%zd' expects type 'signed size_t', but argument 7 has type 'int'
drivers/mtd/ubi/io.c:177: warning: too many arguments for format

Also, amend the ECC error code string and add brackets and whitespace
there - this should make the message readable.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Generate random image_seq when attaching empty MTD device (kernel do the
ubi formating).
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch improves the way UBI handles corrupted flash, or flash
containing garbage or non-UBI data, which is the same from UBI POW.
Namely, we do the following:

* if 5% or more PEBs are corrupted, refuse the flash
* if less than 5% PEBs are corrupted, do not refuse the flash
  and format these PEBs
* if less than 8 PEBs are corrupted, format them silently, otherwise
  print a warning message.
Reported-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>

This is just a preparation patch which introduces several
'struct ubi_scan_info' fields which count eraseblocks of different
types. This will be used later on to decide whether it is safe to
format the flash or not. No functional changes so far.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>

This patch introduces the %UBI_IO_BAD_HDR_READ return code for
the I/O level function. We will use this code in order to distinguish
between "corrupted header possibly because this is non-ubi data" and
"corrupted header possibly because of real data corruption and ECC error".

So far this patch does not introduce any functional change, just a
preparation.

This patch is pased on a patch from
Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>

We do not really need 2 separate error codes for indicating bad VID
and bad EC headers (UBI_IO_BAD_EC_HDR, UBI_IO_BAD_VID_HDR), it is
enough to have only one UBI_IO_BAD_HDR return code.

This patch does not introduce any functional change, only some
code simplification.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>

Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

UBI debugging functions were a little bit over-engineered and
returned more error codes than needed, and the callers had to
do useless checks. Simplify the return codes.

Impact: only debugging code is affected, which means that for
        non-developers this is a no-op patch.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Commit 32bc4820 did not fully fix
the backward compatibility issues. We still fail to properly handle
situations when the first PEB contains non-zero image sequence
number, but one of the following PEBs contains zero image sequence
number. For example, this may happen if we mount a new image with
an old kernel, and then try to mount it in the new kernel.

This patch should fix the issue.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

There was a bug report recently where UBI prints:

UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22

error messages and refuses to attach a PEB. It turned out to be a
buggy flash driver which returned garbage to almost every UBI read.
This patch makes UBI print a better message in such cases. Namely,
if UBI finds 8 or more corrupted PEBs, it prints a warning and
lists the corrupted PEBs.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

If the EC header is corrupted, but the VID header is OK, UBI accepts the
PEB and treats it as "used". However, generally this should not happen.
Print a warning if this happens.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Fall back onto thinking everything's OK if either of the sequence
numbers we are asked to compare is zero, which is what was used
before sequence numbers were introduced.

[ Artem: modified the patch to be applicable to upstream UBI, added
        big comment ]
Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch fixes a bug in the image seq. number handling in the
scanning level. The assignment of the image_seq was incorrect.
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Move the image seq. number handling from I/O level to the scanning
lever, where it really belongs to. Move the @image_seq_set variable
to the @struct ubi_scan_info structure, which exists only during
scanning.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

An image sequence number is added to the UBI erase-counter header
to be able determine if the root file system contains a mixture
of old and new images (because the flashing failed to complete).

A change to nolo is also needed for this to take effect.
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Get rid of 'do_div()' and use more user-friendly primitives from
'linux/math64.h'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

- (better, more, bigger ...) then -> (...) than
Signed-off-by: NFrederik Schwarzer <schwarzerf@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

'ubi_io_read_data()' may return EBADMSG in case of an ECC error,
and we should not panic because of this. We have CRC32 checksum
and may check the data. So just ignore the EBADMSG error.

This patch also fixes a minor spelling error at the same time.
Signed-off-by: NZoltan Sogor <weth@inf.u-szeged.hu>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

In case of error, the function add_volume returns an ERR pointer. The
result of IS_ERR, which is supposed to be used in a test as it is, is
here checked to be less than zero, which seems odd. We suggest to
replace this test by a simple IS_ERR test.

A simplified version of the semantic match that finds this problem is
as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@def0@
expression x;
position p0;
@@
x@p0 = add_volume(...)

@protected@
expression def0.x,E;
position def0.p0;
position p;
statement S;
@@
x@p0
... when != x = E
if (!IS_ERR(x) && ...) {<... x@p ...>} else S

@unprotected@
expression def0.x,E;
identifier fld;
position def0.p0;
position p != protected.p;
@@
x@p0
... when != x = E
* x@p->fld
// </smpl>
Signed-off-by: NJulien Brunel <brunel@diku.dk>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Before UBI got into mainline, there was a slight flash format
change - we did not have sequence number support, then added it.

We have carried full support of those ancient images till this
moment. Now the support is removed, well, not fully removed.

Now UBI will support only _clean_ old images, which were cleanly
detached last time (just before kernel upgrade). This is most
likely the case.

But we will not support unclean ancient images. Surprisingly,
this allows us to remove a big chunk of legacy code.

And the same should be true for downgrading: clean images should
downgrade fine, but unclean ones will not.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

No functional changes, just tweak comments to make kernel-doc
work fine and stop complaining.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Just out or curiousity ran checkpatch.pl for whole UBI,
and discovered there are quite a few of stylistic issues.
Fix them.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>