All of lore.kernel.org
 help / color / mirror / Atom feed
From: hujianyang <hujianyang@huawei.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: [PATCH] UBIFS: Fix empty_log_bytes()  computing error
Date: Fri, 11 Jul 2014 10:13:37 +0800	[thread overview]
Message-ID: <53BF4851.4040105@huawei.com> (raw)

Hi Artem,

After several days testing, the error we fixed in commit 642f63ed10,
"UBIFS: fix fatal race condition" comes out again. This commit seems
not working for my problem and I have to research into it again.

With the help of my ubidump tool this time, I got the detailed info
of log area and mst nodes and found a terrible mistake in function
empty_log_bytes().

I used to think this helper function was correct but it truns out I
was wrong. We set @c->min_log_bytes to 0 in ubifs_log_start_commit()
and suppose empty_log_bytes() will return 0 when the log area is full.
But it's not true.

If lhead_lnum + 1 == ltail_lnum and c->lhead_offs == c->leb_size, @h
would equal to @t and empty_log_bytes() will return log_bytes expect 0.

I prefer to add a patch like:

+       if (h == t && c->lhead_offs == c->leb_size)
+               return 0;
+

but I think there may be no other situation that lead @h equal to @t.
So just make this helper function return 0 if @h equal to @t.

This patch also adds an assertion to make sure ltail is not wrapped
by lhead.



Signed-off-by: hujianyang <hujianyang@huawei.com>
---
 fs/ubifs/log.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ubifs/log.c b/fs/ubifs/log.c
index ed24422..c5d0e73 100644
--- a/fs/ubifs/log.c
+++ b/fs/ubifs/log.c
@@ -106,7 +106,7 @@ static inline long long empty_log_bytes(const struct ubifs_info *c)
 	h = (long long)c->lhead_lnum * c->leb_size + c->lhead_offs;
 	t = (long long)c->ltail_lnum * c->leb_size;

-	if (h >= t)
+	if (h > t)
 		return c->log_bytes - h + t;
 	else
 		return t - h;
@@ -240,6 +240,7 @@ int ubifs_add_bud_to_log(struct ubifs_info *c, int jhead, int lnum, int offs)

 	if (c->lhead_offs > c->leb_size - c->ref_node_alsz) {
 		c->lhead_lnum = ubifs_next_log_lnum(c, c->lhead_lnum);
+		ubifs_assert(c->lhead_lnum != c->ltail_lnum);
 		c->lhead_offs = 0;
 	}

-- 
1.8.1.4

             reply	other threads:[~2014-07-11  2:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11  2:13 hujianyang [this message]
2014-07-16 11:03 ` [PATCH] UBIFS: Fix empty_log_bytes() computing error Artem Bityutskiy
2014-07-16 11:44   ` hujianyang
2014-07-16 12:38     ` Artem Bityutskiy
2014-07-16 12:43       ` Artem Bityutskiy

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=53BF4851.4040105@huawei.com \
    --to=hujianyang@huawei.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.