From: hujianyang <hujianyang@huawei.com>
To: Richard Weinberger <richard@nod.at>,
Artem Bityutskiy <dedekind1@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: [PATCH resend] UBIFS: return -EINVAL if first log leb is empty
Date: Sat, 31 Jan 2015 11:43:51 +0800 [thread overview]
Message-ID: <54CC4F77.1000801@huawei.com> (raw)
CS node is recognized as a sign in UBIFS log replay mechanism.
Log relaying during mount should find the CS node in first log
leb at beginning and then replay the following uncommitted
buds.
Here is a bug in log replay path: If first log leb, 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 first log 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 c->cs_sqnum to
guarantee the empty leb is not first log leb and return an
error if the first log leb is incorrectly empty. After this,
we could catch *first log empty* error in place.
Signed-off-by: hujianyang <hujianyang@huawei.com>
---
fs/ubifs/replay.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 3187925..f13f4b2 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -846,7 +846,14 @@ static int replay_log_leb(struct ubifs_info *c, int lnum, int offs, void *sbuf)
}
if (sleb->nodes_cnt == 0) {
- err = 1;
+ if (unlikely(c->cs_sqnum == 0)) {
+ /* This is the first log LEB, should not be empty */
+ ubifs_err("first log leb LEB %d:%d is empty, no CS node exist",
+ lnum, offs);
+ err = -EINVAL;
+ } else {
+ err = 1;
+ }
goto out;
}
--
1.6.0.2
next reply other threads:[~2015-01-31 3:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 3:43 hujianyang [this message]
2015-01-31 9:51 ` [PATCH resend] UBIFS: return -EINVAL if first log leb is empty Artem Bityutskiy
2015-01-31 10:34 ` hujianyang
2015-01-31 12:16 ` Artem Bityutskiy
2015-02-02 3:10 ` hujianyang
2015-02-02 8:20 ` Richard Weinberger
2015-02-02 9:00 ` hujianyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CC4F77.1000801@huawei.com \
--to=hujianyang@huawei.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox