kernel/linux.git/drivers/mtd/ubi/wl.c, branch linux-6.0.y

ubi: fastmap: Check wl_pool for free peb before wear leveling

2022-05-27T14:49:07+00:00

UBI fetches free peb from wl_pool during wear leveling, so UBI should check wl_pool's empty status before wear leveling. Otherwise, UBI will miss wear leveling chances when free pebs are run out. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger

ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty

2022-05-27T14:46:02+00:00

There at least 6 PEBs reserved on UBI device: 1. EBA_RESERVED_PEBS[1] 2. WL_RESERVED_PEBS[1] 3. UBI_LAYOUT_VOLUME_EBS[2] 4. MIN_FASTMAP_RESERVED_PEBS[2] When all ubi volumes take all their PEBs, there are 3 (EBA_RESERVED_PEBS + WL_RESERVED_PEBS + MIN_FASTMAP_RESERVED_PEBS - MIN_FASTMAP_TAKEN_PEBS[1]) free PEBs. Since commit f9c34bb529975fe ("ubi: Fix producing anchor PEBs") and commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering wear level rules") applied, there is only 1 (3 - FASTMAP_ANCHOR_PEBS[1] - FASTMAP_NEXT_ANCHOR_PEBS[1]) free PEB to fill pool and wl_pool, after filling pool, wl_pool is always empty. So, UBI could be stuck in an infinite loop: ubi_thread system_wq wear_leveling_worker <-------------------------------------------------- get_peb_for_wl | // fm_wl_pool, used = size = 0 | schedule_work(&ubi->fm_work) | | update_fastmap_work_fn | ubi_update_fastmap | ubi_refill_pools | // ubi->free_count - ubi->beb_rsvd_pebs < 5 | // wl_pool is not filled with any PEBs | schedule_erase(old_fm_anchor) | ubi_ensure_anchor_pebs | __schedule_ubi_work(wear_leveling_worker) | | __erase_worker | ensure_wear_leveling | __schedule_ubi_work(wear_leveling_worker) -------------------------- , which cause high cpu usage of ubi_bgt: top - 12:10:42 up 5 min, 2 users, load average: 1.76, 0.68, 0.27 Tasks: 123 total, 3 running, 54 sleeping, 0 stopped, 0 zombie PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1589 root 20 0 0 0 0 R 45.0 0.0 0:38.86 ubi_bgt0d 319 root 20 0 0 0 0 I 15.2 0.0 0:15.29 kworker/0:3-eve 371 root 20 0 0 0 0 I 14.9 0.0 0:12.85 kworker/3:3-eve 20 root 20 0 0 0 0 I 11.3 0.0 0:05.33 kworker/1:0-eve 202 root 20 0 0 0 0 I 11.3 0.0 0:04.93 kworker/2:3-eve In commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering wear level rules"), there are three key changes: 1) Choose the fastmap anchor when the most free PEBs are available. 2) Enable anchor move within the anchor area again as it is useful for distributing wear. 3) Import a candidate fm anchor and check this PEB's erase count during wear leveling. If the wear leveling limit is exceeded, use the used anchor area PEB with the lowest erase count to replace it. The anchor candidate can be removed, we can check fm_anchor PEB's erase count during wear leveling. Fix it by: 1) Removing 'fm_next_anchor' and check 'fm_anchor' during wear leveling. 2) Preferentially filling one free peb into fm_wl_pool in condition of ubi->free_count > ubi->beb_rsvd_pebs, then try to reserve enough free count for fastmap non anchor pebs after the above prerequisites are met. Then, there are at least 1 PEB in pool and 1 PEB in wl_pool after calling ubi_refill_pools() with all erase works done. Fetch a reproducer in [Link]. Fixes: 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs ... rules") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215407 Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger

mtd: ubi: wl: Fix a couple of kernel-doc issues

2020-11-20T11:37:31+00:00

Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not described in 'schedule_erase' drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown' description in '__erase_worker' Cc: Richard Weinberger Cc: Miquel Raynal Cc: Vignesh Raghavendra Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-13-lee.jones@linaro.org

ubi: check kthread_should_stop() after the setting of task state

2020-09-17T20:55:59+00:00

A detach hung is possible when a race occurs between the detach process and the ubi background thread. The following sequences outline the race: ubi thread: if (list_empty(&ubi->works)... ubi detach: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags) => by kthread_stop() wake_up_process() => ubi thread is still running, so 0 is returned ubi thread: set_current_state(TASK_INTERRUPTIBLE) schedule() => ubi thread will never be scheduled again ubi detach: wait_for_completion() => hung task! To fix that, we need to check kthread_should_stop() after we set the task state, so the ubi thread will either see the stop bit and exit or the task state is reset to runnable such that it isn't scheduled out indefinitely. Signed-off-by: Zhihao Cheng Cc: Fixes: 801c135ce73d5df1ca ("UBI: Unsorted Block Images") Reported-by: syzbot+853639d0cb16c31c7a14@syzkaller.appspotmail.com Signed-off-by: Richard Weinberger

ubi: fastmap: Don't produce the initial next anchor PEB when fastmap is disabled

2020-08-02T21:56:13+00:00

Following process triggers a memleak caused by forgetting to release the initial next anchor PEB (CONFIG_MTD_UBI_FASTMAP is disabled): 1. attach -> __erase_worker -> produce the initial next anchor PEB 2. detach -> ubi_fastmap_close (Do nothing, it should have released the initial next anchor PEB) Don't produce the initial next anchor PEB in __erase_worker() when fastmap is disabled. Signed-off-by: Zhihao Cheng Suggested-by: Sascha Hauer Fixes: f9c34bb529975fe ("ubi: Fix producing anchor PEBs") Reported-by: syzbot+d9aab50b1154e3d163f5@syzkaller.appspotmail.com Signed-off-by: Richard Weinberger

ubi: Select fastmap anchor PEBs considering wear level rules

2020-06-02T20:53:05+00:00

There is a risk that the fastmap anchor PEB is alternating between just two PEBs, the current anchor and the previous anchor that was just deleted. As the fastmap pools gets the first take on free PEBs, the pools may leave no free PEBs to be selected as the new anchor, resulting in the two PEBs alternating behaviour. If the anchor PEBs gets a high erase count the PEBs will not be used by the pools but remain in ubi->free, even more increasing the likelihood they will be used as anchors. Getting stuck using only a couple of PEBs continuously will result in an uneven wear, eventually leading to failure. To fix this: - Choose the fastmap anchor when the most free PEBs are available. This is during rebuilding of the fastmap pools, after the unused pool PEBs are added to ubi->free but before the pools are populated again from the free PEBs. Also reserve an additional second best PEB as a candidate for the next time the fast map anchor is updated. If a better PEB is found the next time the fast map anchor is updated, the candidate is made available for building the pools. - Enable anchor move within the anchor area again as it is useful for distributing wear. - The anchor candidate for the next fastmap update is the most suited free PEB. Check this PEB's erase count during wear leveling. If the wear leveling limit is exceeded, the PEB is considered unsuitable for now. As all other non used anchor area PEBs should be even worse, free up the used anchor area PEB with the lowest erase count. Signed-off-by: Arne Edholm Signed-off-by: Richard Weinberger

ubi: fastmap: Only produce the initial anchor PEB when fastmap is used

2020-03-30T21:02:36+00:00

Don't produce the initial anchor PEB when ubi device is read-only or fastmap is disabled, else the resulting PEB will be unusable to any volume. Signed-off-by: Hou Tao Signed-off-by: Richard Weinberger

ubi: wl: Remove set but not used variable 'prev_e'

2020-01-16T22:35:20+00:00

Fixes gcc '-Wunused-but-set-variable' warning: drivers/mtd/ubi/wl.c: In function 'find_wl_entry': drivers/mtd/ubi/wl.c:322:27: warning: variable 'prev_e' set but not used [-Wunused-but-set-variable] It's not used any more now, so remove it. Fixes: f9c34bb52997 ("ubi: Fix producing anchor PEBs") Signed-off-by: YueHaibing Signed-off-by: Richard Weinberger

ubi: Fix producing anchor PEBs

2019-11-17T21:45:57+00:00

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 Signed-off-by: Richard Weinberger

ubi: Don't do anchor move within fastmap area

2019-09-15T19:55:19+00:00

To make sure that Fastmap can use a PEB within the first 64 PEBs, UBI moves blocks away from that area. It uses regular wear-leveling for that job. An anchor move can be triggered if no PEB is free in this area or because of anticipation. In the latter case it can happen that UBI decides to move a block but finds a free PEB within the same area. This case is in vain an increases only erase counters. Catch this case and cancel wear-leveling if this happens. Signed-off-by: Richard Weinberger