summaryrefslogtreecommitdiff
path: root/fs/ubifs/replay.c
AgeCommit message (Collapse)Author
2021-12-23ubifs: Fix spelling mistakesAlexander Dahl
Found with `codespell -i 3 -w fs/ubifs/**` and proof reading that parts. Signed-off-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-06-22ubifs: Fix spelling mistakesZheng Yongjun
Fix some spelling mistakes in comments: withoug ==> without numer ==> number aswell ==> as well referes ==> refers childs ==> children unnecesarry ==> unnecessary Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-05-04Merge tag 'for-linus-5.13-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs Pull JFFS2, UBI and UBIFS updates from Richard Weinberger: "JFFS2: - Use splice_write() - Fix for a slab-out-of-bounds bug UBI: - Fix for clang related warnings - Code cleanup UBIFS: - Fix for inode rebirth at replay - Set s_uuid - Use zstd for default filesystem" * tag 'for-linus-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: ubi: Remove unnecessary struct declaration jffs2: Hook up splice_write callback jffs2: avoid Wempty-body warnings jffs2: Fix kasan slab-out-of-bounds problem ubi: Fix fall-through warnings for Clang ubifs: Report max LEB count at mount time ubifs: Set s_uuid in super block to support ima/evm uuid options ubifs: Default to zstd compression ubifs: Only check replay with inode type to judge if inode linked
2021-04-15ubifs: Only check replay with inode type to judge if inode linkedGuochun Mao
Conside the following case, it just write a big file into flash, when complete writing, delete the file, and then power off promptly. Next time power on, we'll get a replay list like: ... LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80 LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80 LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80 ... In the replay list, data nodes' deletion are 0, and the inode node's deletion is 1. In current logic, the file's dentry will be removed, but inode and the flash space it occupied will be reserved. User will see that much free space been disappeared. We only need to check the deletion value of the following inode type node of the replay entry. Fixes: e58725d51fa8 ("ubifs: Handle re-linking of inodes correctly while recovery") Cc: stable@vger.kernel.org Signed-off-by: Guochun Mao <guochun.mao@mediatek.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-04-08treewide: Change list_sort to use const pointersSami Tolvanen
list_sort() internally casts the comparison function passed to it to a different type with constant struct list_head pointers, and uses this pointer to call the functions, which trips indirect call Control-Flow Integrity (CFI) checking. Instead of removing the consts, this change defines the list_cmp_func_t type and changes the comparison function types of all list_sort() callers to use const pointers, thus avoiding type mismatches. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com
2021-02-12ubifs: replay: Fix high stack usage, againArnd Bergmann
An earlier commit moved out some functions to not be inlined by gcc, but after some other rework to remove one of those, clang started inlining the other one and ran into the same problem as gcc did before: fs/ubifs/replay.c:1174:5: error: stack frame size of 1152 bytes in function 'ubifs_replay_journal' [-Werror,-Wframe-larger-than=] Mark the function as noinline_for_stack to ensure it doesn't happen again. Fixes: f80df3851246 ("ubifs: use crypto_shash_tfm_digest()") Fixes: eb66eff6636d ("ubifs: replay: Fix high stack usage") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-13ubifs: Pass node length in all node dumping callersZhihao Cheng
Function ubifs_dump_node() has been modified to avoid memory oob accessing while dumping node, node length (corresponding to the size of allocated memory for node) should be passed into all node dumping callers. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-13ubifs: Delete duplicated words + other fixesRandy Dunlap
Delete repeated words in fs/ubifs/. {negative, is, of, and, one, it} where "it it" was changed to "if it". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> To: linux-fsdevel@vger.kernel.org Cc: Richard Weinberger <richard@nod.at> Cc: linux-mtd@lists.infradead.org Signed-off-by: Richard Weinberger <richard@nod.at>
2020-09-17ubifs: Fix some kernel-doc warnings in replay.cWang Hai
Fixes the following W=1 kernel build warning(s): fs/ubifs/replay.c:942: warning: Excess function parameter 'ref_lnum' description in 'validate_ref' fs/ubifs/replay.c:942: warning: Excess function parameter 'ref_offs' description in 'validate_ref' They're not in use. Remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-06-01Merge branch 'linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto updates from Herbert Xu: "API: - Introduce crypto_shash_tfm_digest() and use it wherever possible. - Fix use-after-free and race in crypto_spawn_alg. - Add support for parallel and batch requests to crypto_engine. Algorithms: - Update jitter RNG for SP800-90B compliance. - Always use jitter RNG as seed in drbg. Drivers: - Add Arm CryptoCell driver cctrng. - Add support for SEV-ES to the PSP driver in ccp" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (114 commits) crypto: hisilicon - fix driver compatibility issue with different versions of devices crypto: engine - do not requeue in case of fatal error crypto: cavium/nitrox - Fix a typo in a comment crypto: hisilicon/qm - change debugfs file name from qm_regs to regs crypto: hisilicon/qm - add DebugFS for xQC and xQE dump crypto: hisilicon/zip - add debugfs for Hisilicon ZIP crypto: hisilicon/hpre - add debugfs for Hisilicon HPRE crypto: hisilicon/sec2 - add debugfs for Hisilicon SEC crypto: hisilicon/qm - add debugfs to the QM state machine crypto: hisilicon/qm - add debugfs for QM crypto: stm32/crc32 - protect from concurrent accesses crypto: stm32/crc32 - don't sleep in runtime pm crypto: stm32/crc32 - fix multi-instance crypto: stm32/crc32 - fix run-time self test issue. crypto: stm32/crc32 - fix ext4 chksum BUG_ON() crypto: hisilicon/zip - Use temporary sqe when doing work crypto: hisilicon - add device error report through abnormal irq crypto: hisilicon - remove codes of directly report device errors through MSI crypto: hisilicon - QM memory management optimization crypto: hisilicon - unify initial value assignment into QM ...
2020-05-17ubifs: fix wrong use of crypto_shash_descsize()Eric Biggers
crypto_shash_descsize() returns the size of the shash_desc context needed to compute the hash, not the size of the hash itself. crypto_shash_digestsize() would be correct, or alternatively using c->hash_len and c->hmac_desc_len which already store the correct values. But actually it's simpler to just use stack arrays, so do that instead. Fixes: 49525e5eecca ("ubifs: Add helper functions for authentication support") Fixes: da8ef65f9573 ("ubifs: Authenticate replayed journal") Cc: <stable@vger.kernel.org> # v4.20+ Cc: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-05-08ubifs: use crypto_shash_tfm_digest()Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: linux-mtd@lists.infradead.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 336Thomas Gleixner
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 version 2 as published by the free software foundation 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 you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 51 franklin st fifth floor boston ma 02110 1301 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 246 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.674189849@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-25crypto: shash - remove shash_desc::flagsEric Biggers
The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algorithm ever sleeps, making this flag a no-op. With this being the case, inevitably some users who can't sleep wrongly pass MAY_SLEEP. These would all need to be fixed if any shash algorithm actually started sleeping. For example, the shash_ahash_*() functions, which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP from the ahash API to the shash API. However, the shash functions are called under kmap_atomic(), so actually they're assumed to never sleep. Even if it turns out that some users do need preemption points while hashing large buffers, we could easily provide a helper function crypto_shash_update_large() which divides the data into smaller chunks and calls crypto_shash_update() and cond_resched() for each chunk. It's not necessary to have a flag in 'struct shash_desc', nor is it necessary to make individual shash algorithms aware of this at all. Therefore, remove shash_desc::flags, and document that the crypto_shash_*() functions can be called from any context. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-12-13ubifs: Handle re-linking of inodes correctly while recoveryRichard Weinberger
UBIFS's recovery code strictly assumes that a deleted inode will never come back, therefore it removes all data which belongs to that inode as soon it faces an inode with link count 0 in the replay list. Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE it can lead to data loss upon a power-cut. Consider a journal with entries like: 0: inode X (nlink = 0) /* O_TMPFILE was created */ 1: data for inode X /* Someone writes to the temp file */ 2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */ 3: inode X (nlink = 1) /* inode was re-linked via linkat() */ Upon replay of entry #2 UBIFS will drop all data that belongs to inode X, this will lead to an empty file after mounting. As solution for this problem, scan the replay list for a re-link entry before dropping data. Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") Cc: stable@vger.kernel.org Cc: Russell Senior <russell@personaltelco.net> Cc: Rafał Miłecki <zajec5@gmail.com> Reported-by: Russell Senior <russell@personaltelco.net> Reported-by: Rafał Miłecki <zajec5@gmail.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-12-13ubifs: replay: Fix high stack usageArnd Bergmann
Having two shash descriptors on the stack cause a very significant kernel stack usage that can cross the warning threshold: fs/ubifs/replay.c: In function 'authenticate_sleb': fs/ubifs/replay.c:633:1: error: the frame size of 1144 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Normally, gcc optimizes the out, but with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING, it does not. Splitting the two stack allocations into separate functions means that they will use the same memory again. In normal configurations (optimizing for size or performance), those should get inlined and we get the same behavior as before. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-10-23ubifs: Authenticate replayed journalSascha Hauer
Make sure that during replay all buds can be authenticated. To do this we calculate the hash chain until we find an authentication node and check the HMAC in that node against the current status of the hash chain. After a power cut it can happen that some nodes have been written, but not yet the authentication node for them. These nodes have to be discarded during replay. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-10-23ubifs: Add authentication nodes to journalSascha Hauer
Nodes that are written to flash can only be authenticated through the index after the next commit. When a journal replay is necessary the nodes are not yet referenced by the index and thus can't be authenticated. This patch overcomes this situation by creating a hash over all nodes beginning from the commit start node over the reference node(s) and the buds themselves. From time to time we insert authentication nodes. Authentication nodes contain a HMAC from the current hash state, so that they can be used to authenticate a journal replay up to the point where the authentication node is. The hash is continued afterwards so that theoretically we would only have to check the HMAC of the last authentication node we find. Overall we get this picture: ,,,,,,,, ,......,........................................... ,. CS , hash1.----. hash2.----. ,. | , . |hmac . |hmac ,. v , . v . v ,.REF#0,-> bud -> bud -> bud.-> auth -> bud -> bud.-> auth ... ,..|...,........................................... , | , , | ,,,,,,,,,,,,,,, . | hash3,----. , | , |hmac , v , v , REF#1 -> bud -> bud,-> auth ... ,,,|,,,,,,,,,,,,,,,,,, v REF#2 -> ... | V ... Note how hash3 covers CS, REF#0 and REF#1 so that it is not possible to exchange or skip any reference nodes. Unlike the picture suggests the auth nodes themselves are not hashed. With this it is possible for an offline attacker to cut each journal head or to drop the last reference node(s), but not to skip any journal heads or to reorder any operations. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-10-23ubifs: authentication: Add hashes to index nodesSascha Hauer
With this patch the hashes over the index nodes stored in the tree node cache are written to flash and are checked when read back from flash. The hash of the root index node is stored in the master node. During journal replay the hashes are regenerated from the read nodes and stored in the tree node cache. This means the nodes must previously be authenticated by other means. This is done in a later patch. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-10-23ubifs: Add hashes to the tree node cacheSascha Hauer
As part of the UBIFS authentication support every branch in the index gets a hash covering the referenced node. To make that happen the tree node cache needs hashes over the nodes. This patch adds a hash argument to ubifs_tnc_add() and ubifs_tnc_add_nm(). The hashes are calculated from the callers of these functions which actually prepare the nodes. With this patch all the leaf nodes of the index tree get hashes, but currently nothing is done with these hashes, this is left for a later patch. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-08-15ubifs: Pass struct ubifs_info to ubifs_assert()Richard Weinberger
This allows us to have more context in ubifs_assert() and take different actions depending on the configuration. Signed-off-by: Richard Weinberger <richard@nod.at>
2018-06-07ubifs: Spelling fix someting -> somethingSascha Hauer
Replace "someting" with "something" Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2018-06-07ubifs: remove set but never used variableSascha Hauer
replay_sqnum is set but never used. Remove it. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at>
2016-12-12ubifs: Implement encrypted filenamesRichard Weinberger
Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: David Gstir <david@sigma-star.at> Signed-off-by: Richard Weinberger <richard@nod.at>
2016-12-12ubifs: Relax checks in ubifs_validate_entry()Richard Weinberger
With encrypted filenames we store raw binary data, doing string tests is no longer possible. Signed-off-by: Richard Weinberger <richard@nod.at>
2016-10-02UBIFS: improve function-level documentationJulia Lawall
Fix various inconsistencies in the documentation associated with various functions. In the case of fs/ubifs/lprops.c, the second parameter of ubifs_get_lp_stats was renamed from st to lst in commit 84abf972ccff ("UBIFS: add re-mount debugging checks") In the case of fs/ubifs/lpt_commit.c, the excess variables have never existed in the associated functions since the code was introduced into the kernel. The others appear to be straightforward typos. Issues detected using Coccinelle (http://coccinelle.lip6.fr/) Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Richard Weinberger <richard@nod.at>
2015-03-25UBIFS: extend debug/message capabilitiesSheng Yong
In the case where we have more than one volumes on different UBI devices, it may be not that easy to tell which volume prints the messages. Add ubi number and volume id in ubifs_msg/warn/error to help debug. These two values are passed by struct ubifs_info. For those where ubifs_info is not initialized yet, ubifs_* is replaced by pr_*. For those where ubifs_info is not avaliable, ubifs_info is passed to the calling function as a const parameter. The output looks like, [ 95.444879] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 696 [ 95.484688] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "test1" [ 95.484694] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 95.484699] UBIFS (ubi0:1): FS size: 30220288 bytes (28 MiB, 238 LEBs), journal size 1523712 bytes (1 MiB, 12 LEBs) [ 95.484703] UBIFS (ubi0:1): reserved for root: 1427378 bytes (1393 KiB) [ 95.484709] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 40DFFC0E-70BE-4193-8905-F7D6DFE60B17, small LPT model [ 95.489875] UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 699 [ 95.529713] UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "test2" [ 95.529718] UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 95.529724] UBIFS (ubi1:0): FS size: 19808256 bytes (18 MiB, 156 LEBs), journal size 1015809 bytes (0 MiB, 8 LEBs) [ 95.529727] UBIFS (ubi1:0): reserved for root: 935592 bytes (913 KiB) [ 95.529733] UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID EEB7779D-F419-4CA9-811B-831CAC7233D4, small LPT model [ 954.264767] UBIFS error (ubi1:0 pid 756): ubifs_read_node: bad node type (255 but expected 6) [ 954.367030] UBIFS error (ubi1:0 pid 756): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1 Signed-off-by: Sheng Yong <shengyong1@huawei.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2015-02-10UBIFS: return -EINVAL if log head is emptyhujianyang
CS node is recognized as a sign in UBIFS log replay mechanism. Log relaying during mount should find the CS node in log head at beginning and then replay the following uncommitted buds. Here is a bug in log replay path: If the log head, which is indicated by @log_lnum in mst_node, is empty, current UBIFS replay nothing and directly mount the partition without any warning. This action will put filesystem in an abnormal state, e.g. space management in LPT area is incorrect to the real space usage in main area. We reproduced this bug by fault injection: turn log head leb into all 0xFF. UBIFS driver mount the polluted partition normally. But errors occur while running fs_stress on this mount: [89068.055183] UBI error: ubi_io_read: error -74 (ECC error) while reading 59 bytes from PEB 711:33088, read 59 bytes [89068.179877] UBIFS error (pid 10517): ubifs_check_node: bad magic 0x101031, expected 0x6101831 [89068.179882] UBIFS error (pid 10517): ubifs_check_node: bad node at LEB 591:28992 [89068.179891] Not a node, first 24 bytes: [89068.179892] 00000000: 31 10 10 00 37 84 64 04 10 04 00 00 00 00 00 00 20 00 00 00 02 01 00 00 1...7.d......... ....... [89068.180282] UBIFS error (pid 10517): ubifs_read_node: expected node type 2 This patch fix the problem by checking *lnum* to guarantee the empty leb is not log head leb and return an error if the log head leb is incorrectly empty. After this, we could catch *log head empty* error in place. Signed-off-by: hujianyang <hujianyang@huawei.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-08-31UBIFS: print lessArtem Bityutskiy
UBIFS currently prints a lot of information when it mounts a volume, which bothers some people. Make it less chatty - print only important information by default. Get rid of 'dbg_msg()' macro completely. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-08-31UBIFS: comply with coding styleArtem Bityutskiy
Join all the split printk lines in order to stop checkpatch complaining. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-08-21UBIFS: fix replay regressionArtem Bityutskiy
Commit "d51f17e UBIFS: simplify reply code a bit" introduces a bug with the following symptoms: UBIFS error (pid 1): replay_log_leb: first CS node at LEB 3:0 has wrong commit number 0 expected 1 The issue is that we start replaying the log from UBIFS_LOG_LNUM instead of c->lhead_lnum. This patch fixes that. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-07-20UBIFS: simplify reply code a bitArtem Bityutskiy
In the log reply code we assume that 'c->lhead_offs' is known and may be non-zero, which is not the case because we do not store it in the master node and have to find out by scanning on every mount. Knowing this fact allows us to simplify the log scanning loop a bit and remove a couple of unneeded local variables. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
2012-05-20UBI: Kill data type hintRichard Weinberger
We do not need this feature and to our shame it even was not working and there was a bug found very recently. -- Artem Bityutskiy Without the data type hint UBI2 (fastmap) will be easier to implement. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-05-16UBIFS: get rid of dbg_errArtem Bityutskiy
This patch removes the 'dbg_err()' macro and we now use 'ubifs_err()' instead. The idea of 'dbg_err()' was to compile out some error message to make the binary a bit smaller - but I think it was a bad idea. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-05-16UBIFS: rename dumping functionsArtem Bityutskiy
This commit re-names all functions which dump something from "dbg_dump_*()" to "ubifs_dump_*()". This is done for consistency with UBI and because this way it will be more logical once we remove the debugging sompilation option. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-01-13UBIFS: fix key printingArtem Bityutskiy
Before commit 56e46742e846e4de167dde0e1e1071ace1c882a5 we have had locking around all printing macros and we could use static buffers for creating key strings and printing them. However, now we do not have that locking and we cannot use static buffers. This commit removes the old DBGKEY() macros and introduces few new helper macros for printing debugging messages plus a key at the end. Thankfully, all the messages are already structures in a way that the key is printed in the end. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2011-07-04UBIFS: switch to ubifs_leb_readArtem Bityutskiy
Instead of using 'ubi_read()' function directly, used the 'ubifs_leb_read()' helper function instead. This allows to get rid of several redundant error messages and make sure that we always have a stack dump on read errors. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-06-01UBIFS: amend ubifs_recover_leb interfaceArtem Bityutskiy
Instead of passing "grouped" parameter to 'ubifs_recover_leb()' which tells whether the nodes are grouped in the LEB to recover, pass the journal head number and let 'ubifs_recover_leb()' look at the journal head's 'grouped' flag. This patch is a preparation to a further fix where we'll need to know the journal head number for other purposes. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: expect corruption only in last journal head LEBsArtem Bityutskiy
This patch improves UBIFS recovery and teaches it to expect corruption only in the last buds. Indeed, currently we just recover all buds, which is incorrect because only the last buds can have corruptions in case of a power cut. So it is inconsistent with the rest of the recovery strategy which tries hard to distinguish between corruptions cause by power cuts and other types of corruptions. This patch also adds one quirk - a bit older UBIFS was could have corruption in the next to last bud because of the way it switched buds: when bud A is full, it first searched for the next bud B, the wrote a reference node to the log about B, and then synchronized the write-buffer of A. So we could end up with buds A and B, where B is the last, but A had corruption. The UBIFS behavior was fixed, though, so currently it always first synchronizes A's write-buffer and only after this adds B to the log. However, to be make sure that we handle unclean (after a power cut) UBIFS images belonging to older UBIFS - we need to add a quirk and keep it for some time: we need to check for the situation described above. Thankfully, it is easy to check for that situation. When UBIFS adds B to the log, it always first unmaps B, then maps it, and then syncs A's write-buffer. Thus, in that situation we can check that B is empty, in which case it is OK to have corruption in A. To check that B is empty it is enough to just read the first few bytes of the bud and compare them with 0xFFs. This quirk may be removed in a couple of years. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: remove BUG statementArtem Bityutskiy
Remove a 'BUG()' statement when we are unable to find a bud and add a similar 'ubifs_assert()' statement instead. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: change bud replay function conventionsArtem Bityutskiy
This is a minor preparation patch which changes 'replay_bud()' interface - instead of passing bud lnum, offs, jhead, etc directly, pass a pointer to the bud entry which contains all the information. The bud entry will be also needed in one of the following patches. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: substitute the replay tree with a replay listArtem Bityutskiy
This patch simplifies replay even further - it removes the replay tree and adds the replay list instead. Indeed, we just do not need to use a tree here - all we need to do is to add all nodes to the list and then sort it. Using RB-tree is an overkill - more code and slower. And since we replay buds in order, we expect the nodes to follow in _mostly_ sorted order, so the merge sort becomes much cheaper in average than an RB-tree. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: simplify replayArtem Bityutskiy
This patch simplifies the replay code and makes it smaller. First of all, we can notice that we do not really need to create bud replay entries and insert them to the replay tree, because the only reason we do this is to set buds lprops correctly at the end. Instead, we can just walk the list of buds at the very end and set lprops for each bud. This allows us to get rid of whole 'insert_ref_node()' function, the 'REPLAY_REF' flag, and several fields in 'struct replay_entry'. Then we can also notice that we do not need the 'flags' 'struct replay_entry' field, because there is only one flag - 'REPLAY_DELETION'. Instead, we can just add a 'deletion' bit fields. As a result, this patch deletes much more lines that in adds. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: store free and dirty space in the bud replay entryArtem Bityutskiy
This is just a small preparation patch which adds 'free' and 'drity' fields to 'struct bud_entry'. They will be used to set bud lprops. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: double check that buds are replied in orderArtem Bityutskiy
Commit 52c6e6f990669deac3f370f1603815adb55a1dbd provides misleading infomation in the commit messages - buds are replied in order. And the real reason why that fix helped is probably because it made sure we seek head even in read-only mode (so deferred recovery will have seeked heads). This patch adds an assertion which will fire if we reply buds out of order. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: improve commentaryArtem Bityutskiy
This is a tiny clean-up patch which improves replay commentaries. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-16UBIFS: improve debugging messagesArtem Bityutskiy
Print a bit more information is some recovery and replay paths. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-13UBIFS: introduce a separate structure for budgeting infoArtem Bityutskiy
This patch separates out all the budgeting-related information from 'struct ubifs_info' to 'struct ubifs_budg_info'. This way the code looks a bit cleaner. However, the main driver for this is that we want to save budgeting information and print it later, so a separate data structure for this is helpful. This patch is a preparation for the further debugging output improvements. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2011-05-02UBIFS: seek journal heads to the latest bud in replayArtem Bityutskiy
This is the second fix of the following symptom: UBIFS error (pid 34456): could not find an empty LEB which sometimes happens after power cuts when we mount the file-system - UBIFS refuses it with the above error message which comes from the 'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test with the UBIFS power cut emulation enabled. Analysis of the problem. Currently UBIFS replay seeks the journal heads to the last _replayed_ bud. But the buds are replayed out-of-order, so the replay basically seeks journal heads to the "random" bud belonging to this head, and not to the _last_ one. The result of this is that the GC head may be seeked to a full LEB with no free space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a fully or mostly dirty LEB to match the current GC head (because we need to garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum). So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and also fail. As a result - recovery fails and mounting fails. This patch teaches the replay to initialize the GC heads exactly to the latest buds, i.e. the buds which have the largest sequence number in corresponding log reference nodes. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Cc: stable@kernel.org
2010-10-21UBIFS: do not allocate unneeded scan bufferArtem Bityutskiy
In 'ubifs_replay_journal()' we allocate 'sbuf' for scanning the log. However, we already have 'c->sbuf' for these purposes, so do not allocate yet another one. This reduces UBIFS memory consumption while recovering. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>