<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mtd/ubi/fastmap.c, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-03T13:19:27+00:00</updated>
<entry>
<title>ubi: correct the calculation of fastmap size</title>
<updated>2024-04-03T13:19:27+00:00</updated>
<author>
<name>Zhang Yi</name>
<email>yi.zhang@huawei.com</email>
</author>
<published>2024-02-20T02:49:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d1442eeb93689902b8fea2efe041d3054814c86'/>
<id>urn:sha1:5d1442eeb93689902b8fea2efe041d3054814c86</id>
<content type='text'>
[ Upstream commit 7f174ae4f39e8475adcc09d26c5a43394689ad6c ]

Now that the calculation of fastmap size in ubi_calc_fm_size() is
incorrect since it miss each user volume's ubi_fm_eba structure and the
Internal UBI volume info. Let's correct the calculation.

Cc: stable@vger.kernel.org
Signed-off-by: Zhang Yi &lt;yi.zhang@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Use the bitmap API to allocate bitmaps</title>
<updated>2022-09-21T09:32:58+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2022-07-04T18:46:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7f35da21f6f8c6a8c7d262dd4e4bd32e3083f79'/>
<id>urn:sha1:e7f35da21f6f8c6a8c7d262dd4e4bd32e3083f79</id>
<content type='text'>
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.

It is less verbose and it improves the semantic.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty</title>
<updated>2022-05-27T14:46:02+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2022-05-10T12:31:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d09e9a2bddba6c48e0fddb16c4383172ac593251'/>
<id>urn:sha1:d09e9a2bddba6c48e0fddb16c4383172ac593251</id>
<content type='text'>
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 &lt;--------------------------------------------------
  get_peb_for_wl							|
    // fm_wl_pool, used = size = 0					|
    schedule_work(&amp;ubi-&gt;fm_work)					|
									|
		    update_fastmap_work_fn				|
		      ubi_update_fastmap				|
			ubi_refill_pools				|
			// ubi-&gt;free_count - ubi-&gt;beb_rsvd_pebs &lt; 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-&gt;free_count &gt; ubi-&gt;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 &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Return error code if memory allocation fails in add_aeb()</title>
<updated>2022-01-10T22:09:08+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2021-12-27T03:22:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3c07fc25f37c157fde041b3a0c3dfcb1590cbce'/>
<id>urn:sha1:c3c07fc25f37c157fde041b3a0c3dfcb1590cbce</id>
<content type='text'>
Abort fastmap scanning and return error code if memory allocation fails
in add_aeb(). Otherwise ubi will get wrong peb statistics information
after scanning.

Fixes: dbb7d2a88d2a7b ("UBI: Add fastmap core")
Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: Select fastmap anchor PEBs considering wear level rules</title>
<updated>2020-06-02T20:53:05+00:00</updated>
<author>
<name>Arne Edholm</name>
<email>arne.edholm@axis.com</email>
</author>
<published>2020-01-13T14:56:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b68bf9a69d22dd512d61d5f0ba01b065b01ede6'/>
<id>urn:sha1:4b68bf9a69d22dd512d61d5f0ba01b065b01ede6</id>
<content type='text'>
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-&gt;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-&gt;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 &lt;arne.edholm@axis.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: Fix an error pointer dereference in error handling code</title>
<updated>2020-01-19T22:23:28+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-01-13T13:23:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d3805af279c93ef49a64701f35254676d709622'/>
<id>urn:sha1:5d3805af279c93ef49a64701f35254676d709622</id>
<content type='text'>
If "seen_pebs = init_seen(ubi);" fails then "seen_pebs" is an error pointer
and we try to kfree() it which results in an Oops.

This patch re-arranges the error handling so now it only frees things
which have been allocated successfully.

Fixes: daef3dd1f0ae ("UBI: Fastmap: Add self check to detect absent PEBs")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Fix inverted logic in seen selfcheck</title>
<updated>2020-01-16T22:34:50+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2019-10-23T09:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ef5aafb6e4e9942a28cd300bdcda21ce6cbaf045'/>
<id>urn:sha1:ef5aafb6e4e9942a28cd300bdcda21ce6cbaf045</id>
<content type='text'>
set_seen() sets the bit corresponding to the PEB number in the bitmap,
so when self_check_seen() wants to find PEBs that haven't been seen we
have to print the PEBs that have their bit cleared, not the ones which
have it set.

Fixes: 5d71afb00840 ("ubi: Use bitmaps in Fastmap self-check code")
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: Fix producing anchor PEBs</title>
<updated>2019-11-17T21:45:57+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2019-11-05T08:12:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9c34bb529975fe9f85b870a80c53a83a3c5a182'/>
<id>urn:sha1:f9c34bb529975fe9f85b870a80c53a83a3c5a182</id>
<content type='text'>
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 &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 286</title>
<updated>2019-06-05T15:36:37+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-29T14:18:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50acfb2b76e19f73270fef9a32726c7e18d08ec3'/>
<id>urn:sha1:50acfb2b76e19f73270fef9a32726c7e18d08ec3</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation version 2 this program is distributed
  in the hope that it will be useful but without any warranty without
  even the implied warranty of merchantability or fitness for a
  particular purpose see the gnu general public license for more
  details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 97 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Reviewed-by: Alexios Zavras &lt;alexios.zavras@intel.com&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.025053186@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Check each mapping only once</title>
<updated>2018-06-07T13:53:16+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2018-05-28T20:04:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34653fd8c46e771585fce5975e4243f8fd401914'/>
<id>urn:sha1:34653fd8c46e771585fce5975e4243f8fd401914</id>
<content type='text'>
Maintain a bitmap to keep track of which LEB-&gt;PEB mapping
was checked already.
That way we have to read back VID headers only once.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
</feed>
