kernel.git/fs/ubifs, branch linux-3.17.y

UBIFS: fix free log space calculation

2014-11-14T18:10:23Z

commit ba29e721eb2df6df8f33c1f248388bb037a47914 upstream. Hu (hujianyang ) discovered an issue in the 'empty_log_bytes()' function, which calculates how many bytes are left in the log: " If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h' would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes' instead of 0. " At this point it is not clear what would be the consequences of this, and whether this may lead to any problems, but this patch addresses the issue just in case. Tested-by: hujianyang Reported-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman

UBIFS: fix a race condition

2014-11-14T18:10:23Z

commit 052c28073ff26f771d44ef33952a41d18dadd255 upstream. Hu (hujianyang@huawei.com) discovered a race condition which may lead to a situation when UBIFS is unable to mount the file-system after an unclean reboot. The problem is theoretical, though. In UBIFS, we have the log, which basically a set of LEBs in a certain area. The log has the tail and the head. Every time user writes data to the file-system, the UBIFS journal grows, and the log grows as well, because we append new reference nodes to the head of the log. So the head moves forward all the time, while the log tail stays at the same position. At any time, the UBIFS master node points to the tail of the log. When we mount the file-system, we scan the log, and we always start from its tail, because this is where the master node points to. The only occasion when the tail of the log changes is the commit operation. The commit operation has 2 phases - "commit start" and "commit end". The former is relatively short, and does not involve much I/O. During this phase we mostly just build various in-memory lists of the things which have to be written to the flash media during "commit end" phase. During the commit start phase, what we do is we "clean" the log. Indeed, the commit operation will index all the data in the journal, so the entire journal "disappears", and therefore the data in the log become unneeded. So we just move the head of the log to the next LEB, and write the CS node there. This LEB will be the tail of the new log when the commit operation finishes. When the "commit start" phase finishes, users may write more data to the file-system, in parallel with the ongoing "commit end" operation. At this point the log tail was not changed yet, it is the same as it had been before we started the commit. The log head keeps moving forward, though. The commit operation now needs to write the new master node, and the new master node should point to the new log tail. After this the LEBs between the old log tail and the new log tail can be unmapped and re-used again. And here is the possible problem. We do 2 operations: (a) We first update the log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we write the master node (see the big lock of code in 'do_commit()'). But nothing prevents the log head from moving forward between (a) and (b), and the log head may "wrap" now to the old log tail. And when the "wrap" happens, the contends of the log tail gets erased. Now a power cut happens and we are in trouble. We end up with the old master node pointing to the old tail, which was erased. And replay fails because it expects the master node to point to the correct log tail at all times. This patch merges the abovementioned (a) and (b) operations by moving the master node change code to the 'ubifs_log_end_commit()' function, so that it runs with the log mutex locked, which will prevent the log from being changed benween operations (a) and (b). Reported-by: hujianyang Tested-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman

UBIFS: Add log overlap assertions

2014-07-31T12:52:51Z

We use a circle area to record the log nodes in ubifs. This log area should not be overlapped. But after researching the code, I found some conditions may lead log head wraps log ltail. Although we've fixed the problems discovered, there may be some other issues still left. This patch adds assertions where lhead changes to next leb to make sure ltail is not wrapped. Signed-off-by: hujianyang Signed-off-by: Artem Bityutskiy

Revert "UBIFS: add a log overlap assertion"

2014-07-28T16:15:19Z

This reverts commit 545f7fdf6db866c26ac92346b35bc6489fb926d1. Hujianyang's testing revealed that the patch is bogus. Signed-off-by: Artem Bityutskiy

UBIFS: add a log overlap assertion

2014-07-19T06:55:19Z

Add an assertion which checkes that the head of the log never overlaps with the tail of the log. Suggested-by: hujianyang Signed-off-by: Artem Bityutskiy

UBIFS: remove unnecessary check

2014-07-19T06:54:25Z

Remove the "if (c->lhead_offs == 0)" check because is unnecessary, since at that point the log head offset is guaranteed to be zero due to the previous operation. Signed-off-by: Artem Bityutskiy

UBIFS: remove mst_mutex

2014-07-19T06:53:52Z

The 'mst_mutex' is not needed since because 'ubifs_write_master()' is only called on the mount path and commit path. The mount path is sequential and there is no parallelism, and the commit path is also serialized - there is only one commit going on at a time. Signed-off-by: Artem Bityutskiy

UBIFS: kernel-doc warning fix

2014-07-19T06:53:52Z

s/data/timer Signed-off-by: Fabian Frederick Signed-off-by: Artem Bityutskiy

UBIFS: replace seq_printf by seq_puts

2014-07-19T06:53:52Z

Fix checkpatch warnings: "WARNING: Prefer seq_puts to seq_printf" Andrew Morton wrote: " - puts is presumably faster - puts doesn't go rogue if you accidentally pass it a "%". - this patch actually made fs/ubifs/super.o 12 bytes smaller. Perhaps because seq_printf() is a varargs function, forcing the caller to pass args on the stack instead of in registers. " Signed-off-by: Fabian Frederick Signed-off-by: Artem Bityutskiy

UBIFS: replace count*size kzalloc by kcalloc

2014-07-19T06:53:52Z

kcalloc manages count*sizeof overflow. Signed-off-by: Fabian Frederick Signed-off-by: Artem Bityutskiy