JFFS2 eats memory
Øyvind Harboe
oyvind.harboe at zylin.com
Wed Jul 21 02:25:33 EDT 2004
On Wed, 2004-07-21 at 00:08, David Woodhouse wrote:
> On Tue, 2004-07-20 at 20:52 +0200, Øyvind Harboe wrote:
> > I caught it in gc.c where at some point the code assumes that gc_node
> > does not change beneath it. Don't remember.
>
> Hmmm. That sounds like it could break anyway. Can you be more specific?
1. Set jeb->gc_node = NULL; at the end of jffs2_mark_node_obsolete();
2. fire up the debugger and start writing to the JFFS2 disk.
3. See below...
in gc.c:
240
- 241 if (!raw->next_in_ino) {
242 /* Inode-less node. Clean marker, snapshot or something like
that */
243 /* FIXME: If it's something that needs to be copied, including
something
244 we don't grok that has JFFS2_NODETYPE_RWCOMPAT_COPY, we
should do so */
245 spin_unlock(&c->erase_completion_lock);
- 246 jffs2_mark_node_obsolete(c, raw);
- 247 up(&c->alloc_sem);
- 248 goto eraseit_lock;
249 }
250
----- Here raw == NULL, hence jffs2_raw_ref_to_ic() crashes.
- 251 ic = jffs2_raw_ref_to_ic(raw);
> Also, memset the raw_node_ref to 0xdeadbeef before you free it. (Or run
> with slab poisoning enabled in Linux). We should go through the code and
> make sure manually that nothing's going to dereference a pointer to the
> old node after it's freed, but the poisoning is a quick and useful
> debugging aid.
eCos, which I'm using, has this facility built in:
CYGDBG_MEMALLOC_ALLOCATOR_DLMALLOC_DEBUG
--
Øyvind Harboe
http://www.zylin.com
More information about the linux-mtd
mailing list