- 03 10月, 2016 9 次提交
-
-
由 Boris Brezillon 提交于
Currently, all VID headers are allocated and freed using the ubi_zalloc_vid_hdr() and ubi_free_vid_hdr() function. These functions make sure to align allocation on ubi->vid_hdr_alsize and adjust the vid_hdr pointer to match the ubi->vid_hdr_shift requirements. This works fine, but is a bit convoluted. Moreover, the future introduction of LEB consolidation (needed to support MLC/TLC NANDs) will allows a VID buffer to contain more than one VID header. Hence the creation of a ubi_vid_io_buf struct to attach extra information to the VID header. We currently only store the actual pointer of the underlying buffer, but will soon add the number of VID headers contained in the buffer. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
This is part of our attempt to hide EBA internals from other part of the implementation in order to easily adapt it to the MLC needs. Here we are creating an ubi_eba_leb_desc struct to hide the way we keep track of the LEB to PEB mapping. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
This not only hides the aeb allocation internals (which is always good in case we ever want to change the allocation system), but also helps us factorize the initialization of some common fields (ec and pnum). Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
ubi_io_{read,write}_data() are wrappers around ubi_io_{read/write}() that are used to read/write eraseblock payload data, which is exactly what fastmap does when calling ubi_io_{read,write}(). Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
Use the ubi_rb_for_each_entry() macro instead of open-coding it. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
Volume creation/search code is duplicated in a few places (fastmap and non fastmap code). Create some helpers to factorize the code. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff). Make sure we scrub the PEB in this case. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Fixes: dbb7d2a8 ("UBI: Add fastmap core") Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
process_pool_aeb() does several times the be32_to_cpu(new_vh->vol_id) operation. Create a temporary variable and do it once. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Boris Brezillon 提交于
process_pool_aeb() re-implements the logic found in ubi_find_volume(). Call ubi_find_volume() to avoid this duplication. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 30 7月, 2016 4 次提交
-
-
由 Richard Weinberger 提交于
...don't waste memory by allocating one sizeof(int) per PEB. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
This helps to detect cases where an user copies an UBI image to another target with different bad blocks. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
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: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 24 5月, 2016 1 次提交
-
-
由 Richard Weinberger 提交于
Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [<ffffffff8140d841>] dump_stack+0x63/0x82 [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi] [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi] [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi] [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi] [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0 [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300 [<ffffffff8124afe0>] ? cdev_put+0x30/0x30 [<ffffffff81244d36>] vfs_open+0x56/0x60 [<ffffffff812545f4>] path_openat+0x4f4/0x1190 [<ffffffff81256621>] do_filp_open+0x91/0x100 [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190 [<ffffffff812450df>] do_sys_open+0x13f/0x210 [<ffffffff812451ce>] SyS_open+0x1e/0x20 [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Cc: <stable@vger.kernel.org> Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 07 11月, 2015 1 次提交
-
-
由 Ezequiel García 提交于
The PEB array is an array of __be32, so let's fix the scan_pool() prototype accordingly. Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 04 10月, 2015 1 次提交
-
-
由 Richard Weinberger 提交于
There is no need to compute pnum again. Signed-off-by: NRichard Weinberger <richard@nod.at> Acked-by: NBrian Norris <computersforpeace@gmail.com>
-
- 03 6月, 2015 1 次提交
-
-
由 shengyong 提交于
Signed-off-by: NSheng Yong <shengyong1@huawei.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 02 6月, 2015 3 次提交
-
-
由 shengyong 提交于
During fastmap attaching, check if a volume already exists when adding the volume to volume tree. NOTE that the issue cannot happen, only if the on-flash fastmap data is modified. Signed-off-by: NSheng Yong <shengyong1@huawei.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 shengyong 提交于
s/fmpl1/fmpl s/fmpl2/fmpl_wl Add "WL" to the error message when wrong WL pool magic number is detected. Signed-off-by: NSheng Yong <shengyong1@huawei.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 shengyong 提交于
Signed-off-by: NSheng Yong <shengyong1@huawei.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 27 3月, 2015 12 次提交
-
-
由 Richard Weinberger 提交于
Use the new WL accessor functions in fastmap. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
This self check allows Fastmap to detect absent PEBs while writing a new fastmap to the MTD device. It will help to find implementation issues in Fastmap. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
If UBI is unable to write the fastmap to the device we have make sure that upon next attach UBI will fall back to scanning mode. In case we cannot ensure that they only thing we can do is falling back to read-only mode. The current error handling code is not powercut proof. It could happen that a powercut while invalidating would lead to a state where an too old fastmap could be used upon attach. This patch addresses the issue by writing a fake fastmap super block to a fresh PEB instead of reerasing the existing one. The fake fastmap super block will UBI case to do a full scan. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
The current code assumes that each fastmap has the same amount of PEBs. So far this is true but will change soon. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
a) Rename ubi->fm_sem to ubi->fm_eba_sem as this semaphore protects EBA changes. b) Turn ubi->fm_mutex into a rw semaphore. It will still serialize fastmap writes but also ensures that ubi_wl_put_peb() is not interrupted by a fastmap write. We use a rw semaphore to allow ubi_wl_put_peb() still to be executed in parallel if no fastmap write is happening. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
If we set it for dynamic ones we might confuse various self checks. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
If a LEB is unmapped we have to decrement leb_count as well. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
We have to switch to ro mode to guarantee that upon next UBI attach all data is consistent. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
This logic is in vain as we treat protected PEBs also as used, so this case must not happen. If a PEB is found which is in the EBA table but not known as used has to be issued as fatal error. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
It is legal to have PEBs left in the used list. This can happen if UBI copies a PEB and a powercut happens between writing a new fastmap and adding this PEB into the EBA table. In this case the old PEB will be used. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
Currently we leak a few ubi_ainf_pebs while attaching. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
There is no need to allocate new ones every time, we can reuse the existing ones. This makes the code cleaner and more easy to follow. Signed-off-by: NRichard Weinberger <richard@nod.at> Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org> Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>
-
- 28 1月, 2015 1 次提交
-
-
由 Richard Weinberger 提交于
Fastmap can miss a PEB if it is in the protection queue and not jet in the used tree. Treat every protected PEB as used. Signed-off-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 07 11月, 2014 1 次提交
-
-
由 Tanya Brokhman 提交于
If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. The R/O block driver messages were replaced by pr_* since ubi_device structure is not used by it. Amended a bit by Artem. Signed-off-by: NTanya Brokhman <tlinder@codeaurora.org> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 03 10月, 2014 1 次提交
-
-
由 Richard Weinberger 提交于
We need to add fm_sb too. Signed-off-by: NRichard Weinberger <richard@nod.at> Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 16 9月, 2014 1 次提交
-
-
由 Richard Genoud 提交于
I ran into this error after a ubiupdatevol, because I forgot to backport e9110361 UBI: fix the volumes tree sorting criteria. UBI error: process_pool_aeb: orphaned volume in fastmap pool UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan! kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1 [<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14) [<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244) [<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec) [<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868) [<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac) [<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140) [<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0) [<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4) [<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24) UBI: scanning is finished Freeing the cache in the error path fixes the Slab error. Tested on at91sam9g35 (3.14.18+fastmap backports) Signed-off-by: NRichard Genoud <richard.genoud@gmail.com> Cc: stable <stable@vger.kernel.org> # 3.10+
-
- 16 7月, 2014 1 次提交
-
-
由 Brian Norris 提交于
The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'. This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC headers, events and scrubs the affected PEBs. This issue was reported by Coverity Scan. Artem: improved the commit message. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Acked-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 01 7月, 2014 1 次提交
-
-
由 Heiko Schocher 提交于
Commig "604b592e UBI: fix rb_tree node comparison in add_map" broke fastmap backward compatibility and older fastmap images cannot be mounted anymore. The reason is that it changes the volumes RB-tree sorting criteria. This patch fixes the problem. Artem: re-write the commit message Signed-off-by: NHeiko Schocher <hs@denx.de> Acked-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 13 5月, 2014 1 次提交
-
-
由 Mike Snitzer 提交于
The comparisons used in add_vol() shouldn't be identical. Pretty sure the following is correct but it is completely untested. Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
- 04 2月, 2014 1 次提交
-
-
由 Dan Carpenter 提交于
Move the kmem_cache_free() calls down a couple lines. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-