All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>,
	linux-mtd@lists.infradead.org
Subject: [BUG] 2.6.8-rc3 jffs2 unable to read filesystems
Date: Sat, 7 Aug 2004 14:18:29 +0100	[thread overview]
Message-ID: <20040807141829.D2805@flint.arm.linux.org.uk> (raw)

The following two messages sum up the problem:

JFFS2 compression type 0x5a06 not avaiable.
Error: jffs2_decompress returned -5

It appears that a jffs2 change committed on July 15th has caused recent
2.6.8-rc kernels to be incompatible with jffs2 filesystems modified by
previous kernel versions.

The "new format" jffs2 filesystem uses both "compr" and "usercompr"
of the jffs2_raw_inode structure, whereas previous implementations
left "usercompr" uninitialised and thus contains random data.

This can be seen by tracing through the code from jffs2_alloc_raw_inode()
and noticing that previous implementations do not initialise this field -
AFAICS kmem_cache_alloc() does not guarantee that memory returned by
this function will be initialised.

Therefore, recent 2.6.8-rc kernels must _NOT_ use this field if they
wish to remain compatible with existing jffs2 filesystems.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>,
	linux-mtd@lists.infradead.org
Subject: [BUG] 2.6.8-rc3 jffs2 unable to read filesystems
Date: Sat, 7 Aug 2004 14:18:29 +0100	[thread overview]
Message-ID: <20040807141829.D2805@flint.arm.linux.org.uk> (raw)

The following two messages sum up the problem:

JFFS2 compression type 0x5a06 not avaiable.
Error: jffs2_decompress returned -5

It appears that a jffs2 change committed on July 15th has caused recent
2.6.8-rc kernels to be incompatible with jffs2 filesystems modified by
previous kernel versions.

The "new format" jffs2 filesystem uses both "compr" and "usercompr"
of the jffs2_raw_inode structure, whereas previous implementations
left "usercompr" uninitialised and thus contains random data.

This can be seen by tracing through the code from jffs2_alloc_raw_inode()
and noticing that previous implementations do not initialise this field -
AFAICS kmem_cache_alloc() does not guarantee that memory returned by
this function will be initialised.

Therefore, recent 2.6.8-rc kernels must _NOT_ use this field if they
wish to remain compatible with existing jffs2 filesystems.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

             reply	other threads:[~2004-08-07 13:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-07 13:18 Russell King [this message]
2004-08-07 13:18 ` [BUG] 2.6.8-rc3 jffs2 unable to read filesystems Russell King
2004-08-07 21:58 ` David Woodhouse
2004-08-07 21:58   ` David Woodhouse
2004-08-07 22:45   ` Russell King
2004-08-07 22:45     ` Russell King

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=20040807141829.D2805@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --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.