<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/mtd/ubi/ubi.h, branch linux-rolling-lts</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-rolling-lts</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-rolling-lts'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-01-18T14:28:19Z</updated>
<entry>
<title>ubi: Revert "ubi: wl: Close down wear-leveling before nand is suspended"</title>
<updated>2025-01-18T14:28:19Z</updated>
<author>
<name>Zhihao Cheng</name>
</author>
<published>2024-12-14T11:01:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=844c6fdc13cf3d9d251533631988a58f8356a8c8'/>
<id>urn:sha1:844c6fdc13cf3d9d251533631988a58f8356a8c8</id>
<content type='text'>
Commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is
suspended") added a reboot notification in UBI layer to shutdown the
wear-leveling subsystem, which imported an UAF problem[1]. Besides that,
the method also brings other potential UAF problems, for example:
       reboot             kworker
 ubi_wl_reboot_notifier
  ubi_wl_close
   ubi_fastmap_close
    kfree(ubi-&gt;fm)
                     update_fastmap_work_fn
		      ubi_update_fastmap
		       old_fm = ubi-&gt;fm
		       if (old_fm &amp;&amp; old_fm-&gt;e[i]) // UAF!

Actually, the problem fixed by commit 5580cdae05ae ("ubi: wl: Close down
wear-leveling before nand is suspended") has been solved by commit
8cba323437a4 ("mtd: rawnand: protect access to rawnand devices while in
suspend"), which was discussed in [2]. So we can revert the commit
5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is
suspended") directly.

[1] https://lore.kernel.org/linux-mtd/20241208175211.9406-2-dennis.lamerice@gmail.com/
[2] https://lore.kernel.org/all/9bf76f5d-12a4-46ff-90d4-4a7f0f47c381@axis.com/

Fixes: 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended")
Reported-by: Dennis Lam &lt;dennis.lamerice@gmail.com&gt;
Closes: https://lore.kernel.org/linux-mtd/20241208175211.9406-2-dennis.lamerice@gmail.com/
Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Acked-by: Mårten Lindahl &lt;marten.lindahl@axis.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: wl: Close down wear-leveling before nand is suspended</title>
<updated>2024-11-14T17:46:04Z</updated>
<author>
<name>Mårten Lindahl</name>
</author>
<published>2024-09-07T19:28:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5580cdae05aefa96deebd7f5ade9d70c92adabd7'/>
<id>urn:sha1:5580cdae05aefa96deebd7f5ade9d70c92adabd7</id>
<content type='text'>
If a reboot/shutdown signal with double force (-ff) is triggered when
the erase worker or wear-leveling worker function runs we may end up in
a race condition since the MTD device gets a reboot notification and
suspends the nand flash before the erase or wear-leveling is done. This
will reject all accesses to the flash with -EBUSY.

Sequence for the erase worker function:

   systemctl reboot -ff           ubi_thread

                                do_work
 __do_sys_reboot
   blocking_notifier_call_chain
     mtd_reboot_notifier
       nand_shutdown
         nand_suspend
                                  __erase_worker
                                    ubi_sync_erase
                                      mtd_erase
                                        nand_erase_nand

                                          # Blocked by suspended chip
                                          nand_get_device
                                            =&gt; EBUSY

Similar sequence for the wear-leveling function:

   systemctl reboot -ff           ubi_thread

                                do_work
 __do_sys_reboot
   blocking_notifier_call_chain
     mtd_reboot_notifier
       nand_shutdown
         nand_suspend
                                  wear_leveling_worker
                                    ubi_eba_copy_leb
                                      ubi_io_write
                                        mtd_write
                                          nand_write_oob

                                            # Blocked by suspended chip
                                            nand_get_device
                                              =&gt; EBUSY

 systemd-shutdown[1]: Rebooting.
 ubi0 error: ubi_io_write: error -16 while writing 2048 bytes to PEB
 CPU: 1 PID: 82 Comm: ubi_bgt0d Kdump: loaded Tainted: G           O
 (unwind_backtrace) from [&lt;80107b9f&gt;] (show_stack+0xb/0xc)
 (show_stack) from [&lt;8033641f&gt;] (dump_stack_lvl+0x2b/0x34)
 (dump_stack_lvl) from [&lt;803b7f3f&gt;] (ubi_io_write+0x3ab/0x4a8)
 (ubi_io_write) from [&lt;803b817d&gt;] (ubi_io_write_vid_hdr+0x71/0xb4)
 (ubi_io_write_vid_hdr) from [&lt;803b6971&gt;] (ubi_eba_copy_leb+0x195/0x2f0)
 (ubi_eba_copy_leb) from [&lt;803b939b&gt;] (wear_leveling_worker+0x2ff/0x738)
 (wear_leveling_worker) from [&lt;803b86ef&gt;] (do_work+0x5b/0xb0)
 (do_work) from [&lt;803b9ee1&gt;] (ubi_thread+0xb1/0x11c)
 (ubi_thread) from [&lt;8012c113&gt;] (kthread+0x11b/0x134)
 (kthread) from [&lt;80100139&gt;] (ret_from_fork+0x11/0x38)
 Exception stack(0x80c43fb0 to 0x80c43ff8)
 ...
 ubi0 error: ubi_dump_flash: err -16 while reading 2048 bytes from PEB
 ubi0 error: wear_leveling_worker: error -16 while moving PEB 246 to PEB
 ubi0 warning: ubi_ro_mode.part.0: switch to read-only mode
 ...
 ubi0 error: do_work: work failed with error code -16
 ubi0 error: ubi_thread: ubi_bgt0d: work failed with error code -16
 ...
 Kernel panic - not syncing: Software Watchdog Timer expired

Add a reboot notification for the ubi/wear-leveling to shutdown any
potential flash work actions before the nand is suspended.

Signed-off-by: Mårten Lindahl &lt;marten.lindahl@axis.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>mtd: ubi: Rmove unused declaration in header file</title>
<updated>2024-11-14T17:02:11Z</updated>
<author>
<name>Zhang Zekun</name>
</author>
<published>2024-09-07T08:00:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb33ade753a6e2d629b4f87d2375ee9063d21bc7'/>
<id>urn:sha1:cb33ade753a6e2d629b4f87d2375ee9063d21bc7</id>
<content type='text'>
The definition of ubi_destroy_ai() has been removed since
commit dac6e2087a41 ("UBI: Add fastmap stuff to attach.c").
Remove the empty declaration in header file.

Signed-off-by: Zhang Zekun &lt;zhangzekun11@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubifs: correct UBIFS_DFS_DIR_LEN macro definition and improve code clarity</title>
<updated>2024-07-12T19:52:24Z</updated>
<author>
<name>ZhaoLong Wang</name>
</author>
<published>2024-04-18T07:07:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7037c96d8c42965eb93e6b96cf921399c283d431'/>
<id>urn:sha1:7037c96d8c42965eb93e6b96cf921399c283d431</id>
<content type='text'>
The UBIFS_DFS_DIR_LEN macro, which defines the maximum length of the UBIFS
debugfs directory name, has an incorrect formula and misleading comments.
The current formula is (3 + 1 + 2*2 + 1), which assumes that both UBI device
number and volume ID are limited to 2 characters. However, UBI device number
ranges from 0 to 31 (2 characters), and volume ID ranges from 0 to 127 (up
to 3 characters).

Although the current code works due to the cancellation of mathematical
errors (9 + 1 = 10, which matches the correct UBIFS_DFS_DIR_LEN value), it
can lead to confusion and potential issues in the future.

This patch aims to improve the code clarity and maintainability by making
the following changes:

1. Corrects the UBIFS_DFS_DIR_LEN macro definition to (3 + 1 + 2 + 3 + 1),
   accommodating the maximum lengths of both UBI device number and volume ID,
   plus the separators and null terminator.
2. Updates the snprintf calls to use UBIFS_DFS_DIR_LEN instead of
   UBIFS_DFS_DIR_LEN + 1, removing the unnecessary +1.
3. Modifies the error checks to compare against UBIFS_DFS_DIR_LEN using &gt;=
   instead of &gt;, aligning with the corrected macro definition.
4. Removes the redundant +1 in the dfs_dir_name array definitions in ubi.h
   and debug.h.

While these changes do not affect the runtime behavior, they make the code
more readable, maintainable, and less prone to future errors.

v2-&gt;v3:

 - Removes the duplicated UBIFS_DFS_DIR_LEN and UBIFS_DFS_DIR_NAME macro
   definitions in ubifs.h, as they are already defined in debug.h.

Signed-off-by: ZhaoLong Wang &lt;wangzhaolong1@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>mtd: ubi: make ubi_class constant</title>
<updated>2024-07-12T17:45:09Z</updated>
<author>
<name>Ricardo B. Marliere</name>
</author>
<published>2024-03-05T19:35:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=299af26eb46374295a3289be990e536b75c9376a'/>
<id>urn:sha1:299af26eb46374295a3289be990e536b75c9376a</id>
<content type='text'>
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the ubi_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ricardo B. Marliere &lt;ricardo@marliere.net&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>mtd: ubi: introduce pre-removal notification for UBI volumes</title>
<updated>2024-02-25T21:41:33Z</updated>
<author>
<name>Daniel Golle</name>
</author>
<published>2023-12-19T02:33:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7e84c961b2eb062d2f47037dcca52dcd1d3615b5'/>
<id>urn:sha1:7e84c961b2eb062d2f47037dcca52dcd1d3615b5</id>
<content type='text'>
Introduce a new notification type UBI_VOLUME_SHUTDOWN to inform users
that a volume is just about to be removed.
This is needed because users (such as the NVMEM subsystem) expect that
at the time their removal function is called, the parenting device is
still available (for removal of sysfs nodes, for example, in case of
NVMEM which otherwise WARNs on volume removal).

Signed-off-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>mtd: ubi: block: use notifier to create ubiblock from parameter</title>
<updated>2024-02-25T21:41:32Z</updated>
<author>
<name>Daniel Golle</name>
</author>
<published>2023-12-19T02:32:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=762d73cd930e3073e927b2ec0811519bde2c8fb4'/>
<id>urn:sha1:762d73cd930e3073e927b2ec0811519bde2c8fb4</id>
<content type='text'>
Use UBI_VOLUME_ADDED notification to create ubiblock device specified
on kernel cmdline or module parameter.
This makes thing more simple and has the advantage that ubiblock devices
on volumes which are not present at the time the ubi module is probed
will still be created.

Suggested-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>ubi: Add six fault injection type for testing</title>
<updated>2024-01-06T22:41:40Z</updated>
<author>
<name>ZhaoLong Wang</name>
</author>
<published>2023-12-26T01:01:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7cd8d1f8475d83c8871917430a2daf362c68e742'/>
<id>urn:sha1:7cd8d1f8475d83c8871917430a2daf362c68e742</id>
<content type='text'>
This commit adds six fault injection type for testing to cover the
abnormal path of the UBI driver.

Inject the following faults when the UBI reads the LEB:
 +----------------------------+-----------------------------------+
 |    Interface name          |       emulate behavior            |
 +----------------------------+-----------------------------------+
 |  emulate_eccerr            | ECC error                         |
 +----------------------------+-----------------------------------+
 |  emulate_read_failure      | read failure                      |
 |----------------------------+-----------------------------------+
 |  emulate_io_ff             | read content as all FF            |
 |----------------------------+-----------------------------------+
 |  emulate_io_ff_bitflips    | content FF with MTD err reported  |
 +----------------------------+-----------------------------------+
 |  emulate_bad_hdr           | bad leb header                    |
 |----------------------------+-----------------------------------+
 |  emulate_bad_hdr_ebadmsg   | bad header with ECC err           |
 +----------------------------+-----------------------------------+

Signed-off-by: ZhaoLong Wang &lt;wangzhaolong1@huawei.com&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: Use the fault injection framework to enhance the fault injection capability</title>
<updated>2024-01-06T22:38:55Z</updated>
<author>
<name>ZhaoLong Wang</name>
</author>
<published>2023-12-26T01:01:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6931fb44858c3b9da9f35fdc8d9cbeef0b4b50a3'/>
<id>urn:sha1:6931fb44858c3b9da9f35fdc8d9cbeef0b4b50a3</id>
<content type='text'>
To make debug parameters configurable at run time, use the
fault injection framework to reconstruct the debugfs interface,
and retain the legacy fault injection interface.

Now, the file emulate_failures and fault_attr files control whether
to enable fault emmulation.

The file emulate_failures receives a mask that controls type and
process of fault injection. Generally, for ease of use, you can
directly enter a mask with all 1s.

echo 0xffff &gt; /sys/kernel/debug/ubi/ubi0/emulate_failures

And you need to configure other fault-injection capabilities for
testing purpose:

echo 100 &gt; /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/probability
echo 15 &gt; /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/space
echo 2 &gt; /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/verbose
echo -1 &gt; /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/times

The CONFIG_MTD_UBI_FAULT_INJECTION to enable the Fault Injection is
added to kconfig.

Signed-off-by: ZhaoLong Wang &lt;wangzhaolong1@huawei.com&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: Add module parameter to control reserving filling pool PEBs</title>
<updated>2023-10-28T21:15:44Z</updated>
<author>
<name>Zhihao Cheng</name>
</author>
<published>2023-08-28T06:38:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d4c48e5b58f12835de779f5425ef741c4d0fb53e'/>
<id>urn:sha1:d4c48e5b58f12835de779f5425ef741c4d0fb53e</id>
<content type='text'>
Adding 6th module parameter in 'mtd=xxx' to control whether or not
reserving PEBs for filling pool/wl_pool.

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