ubi: Fix producing anchor PEBs
authorSascha Hauer <s.hauer@pengutronix.de>
Tue, 5 Nov 2019 08:12:51 +0000 (09:12 +0100)
committerRichard Weinberger <richard@nod.at>
Sun, 17 Nov 2019 21:45:57 +0000 (22:45 +0100)
commitf9c34bb529975fe9f85b870a80c53a83a3c5a182
tree6a5cf84ad65ac0ed3499e10c68803d434b12a59d
parent6abf57262166b4f4294667fb5206ae7ba1ba96f5
ubi: Fix producing anchor PEBs

When a new fastmap is about to be written UBI must make sure it has a
free block for a fastmap anchor available. For this ubi_update_fastmap()
calls ubi_ensure_anchor_pebs(). This stopped working with 2e8f08deabbc
("ubi: Fix races around ubi_refill_pools()"), with this commit the wear
leveling code is blocked and can no longer produce free PEBs. UBI then
more often than not falls back to write the new fastmap anchor to the
same block it was already on which means the same erase block gets
erased during each fastmap write and wears out quite fast.

As the locking prevents us from producing the anchor PEB when we
actually need it, this patch changes the strategy for creating the
anchor PEB. We no longer create it on demand right before we want to
write a fastmap, but instead we create an anchor PEB right after we have
written a fastmap. This gives us enough time to produce a new anchor PEB
before it is needed. To make sure we have an anchor PEB for the very
first fastmap write we call ubi_ensure_anchor_pebs() during
initialisation as well.

Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
drivers/mtd/ubi/fastmap-wl.c
drivers/mtd/ubi/fastmap.c
drivers/mtd/ubi/ubi.h
drivers/mtd/ubi/wl.c
drivers/mtd/ubi/wl.h