linux-stable.git/drivers/mtd/ubi, branch v4.8 Linux kernel stable tree ubi: Use bitmaps in Fastmap self-check code 2016-07-29T21:32:58+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:18+00:00 5d71afb0084053687da6b66ce8133a3df3e52fc6 ...don't waste memory by allocating one sizeof(int) per PEB. Signed-off-by: Richard Weinberger <richard@nod.at> 
...don't waste memory by allocating one sizeof(int) per
PEB.

Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Be more paranoid while seaching for the most recent Fastmap 2016-07-29T21:32:54+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:17+00:00 74f2c6e9a47cf4e508198c8594626cc82906a13d Since PEB erasure is asynchornous it can happen that there is more than one Fastmap on the MTD. This is fine because the attach logic will pick the Fastmap data structure with the highest sequence number. On a not so well configured MTD stack spurious ECC errors are common. Causes can be different, bad hardware, wrong operating modes, etc... If the most current Fastmap renders bad due to ECC errors UBI might pick an older Fastmap to attach from. While this can only happen on an anyway broken setup it will show completely different sympthoms and makes finding the root cause much more difficult. So, be debug friendly and fall back to scanning mode of we're facing an ECC error while scanning for Fastmap. Cc: <stable@vger.kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at> 
Since PEB erasure is asynchornous it can happen that there is
more than one Fastmap on the MTD. This is fine because the attach logic
will pick the Fastmap data structure with the highest sequence number.

On a not so well configured MTD stack spurious ECC errors are common.
Causes can be different, bad hardware, wrong operating modes, etc...
If the most current Fastmap renders bad due to ECC errors UBI might
pick an older Fastmap to attach from.
While this can only happen on an anyway broken setup it will show
completely different sympthoms and makes finding the root cause much
more difficult.
So, be debug friendly and fall back to scanning mode of we're facing
an ECC error while scanning for Fastmap.

Cc: <stable@vger.kernel.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Check whether the Fastmap anchor matches the super block 2016-07-29T21:32:43+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:16+00:00 5283ec72b0cca44ccea63070f6954fd8675b9ac4 This helps to detect cases where an user copies an UBI image to another target with different bad blocks. Signed-off-by: Richard Weinberger <richard@nod.at> 
This helps to detect cases where an user copies an UBI image to
another target with different bad blocks.

Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Rework Fastmap attach base code 2016-07-29T21:32:42+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:15+00:00 fdf10ed710c0aa177e8dfcd84e65e4e5e8e0956b Introduce a new list to the UBI attach information object to be able to deal better with old and corrupted Fastmap eraseblocks. Also move more Fastmap specific code into fastmap.c. Signed-off-by: Richard Weinberger <richard@nod.at> 
Introduce a new list to the UBI attach information
object to be able to deal better with old and corrupted
Fastmap eraseblocks.
Also move more Fastmap specific code into fastmap.c.

Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Fix whitespace issue in count_fastmap_pebs() 2016-07-29T21:32:40+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:14+00:00 be8011053f0678792a1f0adda66fd74a5fe4adc3 Signed-off-by: Richard Weinberger <richard@nod.at> 
Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Introduce vol_ignored() 2016-07-29T21:32:39+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:13+00:00 243a4f8126fcf7facb04b324dbb7c85d10b11ce9 This makes the logic more easy to follow. Signed-off-by: Richard Weinberger <richard@nod.at> 
This makes the logic more easy to follow.

Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Fix scan_fast() comment 2016-07-29T21:32:38+00:00 Richard Weinberger richard@nod.at 2016-06-14T08:12:12+00:00 d139d300a9562fa6571ec95ac6fefd9b1a0a4fd7 Signed-off-by: Richard Weinberger <richard@nod.at> 
Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Make volume resize power cut aware 2016-07-29T21:32:01+00:00 Richard Weinberger richard@nod.at 2016-06-23T17:30:38+00:00 4946784bd3924b1374f05eebff2fd68660bae866 When the volume resize operation shrinks a volume, LEBs will be unmapped. Since unmapping will not erase these LEBs immediately we have to wait for that operation to finish. Otherwise in case of a power cut right after writing the new volume table the UBI attach process can find more LEBs than the volume table knows. This will render the UBI image unattachable. Fix this issue by waiting for erase to complete and write the new volume table afterward. Cc: <stable@vger.kernel.org> Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Richard Weinberger <richard@nod.at> 
When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Cc: <stable@vger.kernel.org>
Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: Fix early logging 2016-07-29T21:31:55+00:00 Richard Weinberger richard@nod.at 2016-07-04T20:06:51+00:00 bc743f34dfa011e62edd0ea4ae8455be06c083b5 We cannot use ubi_* logging functions before the UBI object is initialized. Cc: <stable@vger.kernel.org> Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Richard Weinberger <richard@nod.at> 
We cannot use ubi_* logging functions before the UBI
object is initialized.

Cc: <stable@vger.kernel.org>
Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Richard Weinberger <richard@nod.at>
ubi: gluebi: Fix double refcounting 2016-07-29T21:31:54+00:00 Richard Weinberger richard@nod.at 2016-07-04T20:10:13+00:00 95b54e1e10eb32c465d1028dd119ee790afe4a01 There is no need to call get/put on the module reference in gluebi_get/put_device() callbacks. Since mtd->owner is the gluebi module itself mtdcore.c will take care of proper refcounting in __get/put_mtd_device() before executing the callbacks. Signed-off-by: Richard Weinberger <richard@nod.at> 
There is no need to call get/put on the module
reference in gluebi_get/put_device() callbacks.
Since mtd->owner is the gluebi module itself
mtdcore.c will take care of proper refcounting
in __get/put_mtd_device() before executing the
callbacks.

Signed-off-by: Richard Weinberger <richard@nod.at>