linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] UBIFS: allow for gaps when dirtying the LPT
Date: Fri, 21 Nov 2008 19:19:27 +0200	[thread overview]
Message-ID: <1227287970-14684-6-git-send-email-dedekind@infradead.org> (raw)
In-Reply-To: <1227287970-14684-1-git-send-email-dedekind@infradead.org>

From: Adrian Hunter <ext-adrian.hunter@nokia.com>

The LPT may have gaps in it because initially empty LEBs
are not added by mkfs.ubifs - because it does not know how
many there are.  Then UBIFS allocates empty LEBs in the
reverse order that they are discovered i.e. they are
added to, and removed from, the front of a list.  That
creates a gap in the middle of the LPT.

The function dirtying the LPT tree (for the purpose of
small model garbage collection) assumed that a gap could
only occur at the very end of the LPT and stopped dirtying
prematurely, which in turn resulted in the LPT running
out of space - something that is designed to be impossible.

Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
---
 fs/ubifs/lpt_commit.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index eed5a00..a41434b 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -571,8 +571,6 @@ static struct ubifs_pnode *next_pnode(struct ubifs_info *c,
 		/* We assume here that LEB zero is never an LPT LEB */
 		if (nnode->nbranch[iip].lnum)
 			return ubifs_get_pnode(c, nnode, iip);
-		else
-			return NULL;
 	}
 
 	/* Go up while can't go right */
-- 
1.5.4.3


  parent reply	other threads:[~2008-11-21 15:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 17:19 UBIFS updates for 2.6.28 Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: remove printk Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: endian handling fixes and annotations Artem Bityutskiy
2008-11-22 19:27   ` Sebastian Andrzej Siewior
2008-11-23  3:21     ` Harvey Harrison
2008-11-23  9:28       ` Sebastian Andrzej Siewior
2008-11-23 10:05     ` Jamie Lokier
2008-11-24 14:19     ` Adrian Hunter
2008-11-24 16:46       ` Harvey Harrison
2008-12-02  9:12     ` Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] MAINTAINERS: change UBI/UBIFS git tree URLs Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: fix compilation warnings Artem Bityutskiy
2008-11-22 18:54   ` Sebastian Andrzej Siewior
2008-11-24 10:03     ` Adrian Hunter
2008-11-30 18:58       ` Sebastian Andrzej Siewior
2008-11-21 17:19 ` Artem Bityutskiy [this message]
2008-11-21 17:19 ` [PATCH] UBIFS: do not print scary memory allocation warnings Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: do not allocate too much Artem Bityutskiy
2008-11-21 17:19 ` [PATCH] UBIFS: pre-allocate bulk-read buffer 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=1227287970-14684-6-git-send-email-dedekind@infradead.org \
    --to=dedekind@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).