headers
Guennadi Liakhovetski | 12 Nov 2007 15:45
Picon
Picon
Favicon

[AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)

Hi,

now that our at91rm9200-based system boots 2.6.23 and runs in principle, 
we're getting further bad problems:

1. jffs2. After a few reboots we get lots of

JFFS2 notice: (708) jffs2_get_inode_nodes: Node header CRC failed at ...

they do not come under 2.6.11. Looks like under 2.6.11 this case is just 
not tested, but a few first reboots under 2.6.23 come also clean through, 
so, it is something, that happens later.

Using physmap:

physmap platform flash device: 01000000 at 10000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

2. There has been an Oops once in vi...

Unable to handle kernel paging request at virtual address e5dcc3ec
pgd = c135c000
[e5dcc3ec] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0    Not tainted  (2.6.23.1-ga63c3b88-dirty #52)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Adrian Bunk | 27 Oct 2007 16:18

jffs2_init_acl_post() can return uninitialized variable

Commit cfc8dc6f6f69ede939e09c2af06a01adee577285 added the following 
function that can return the value of an uninitialized variable:

<--  snip  -->

...
int jffs2_init_acl_post(struct inode *inode)
{
        struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
        int rc;

        if (f->i_acl_default) {
                rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_DEFAULT, f->i_acl_default);
                if (rc)
                        return rc;
        }

        if (f->i_acl_access) {
                rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_ACCESS, f->i_acl_access);
                if (rc)
                        return rc;
        }

        return rc;
}
...

<--  snip  -->

Spotted by the Coverity checker.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adrian Bunk | 24 Oct 2007 18:27

[2.6 patch] make jffs2_get_acl() static

jffs2_get_acl() can now become static again.

Signed-off-by: Adrian Bunk <bunk <at> kernel.org>

---

 fs/jffs2/acl.c |    2 +-
 fs/jffs2/acl.h |    2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

add2b887d64536f3fe978e62f0774292456f1ddb 
diff --git a/fs/jffs2/acl.c b/fs/jffs2/acl.c
index 9728614..b14e805 100644
--- a/fs/jffs2/acl.c
+++ b/fs/jffs2/acl.c
 <at>  <at>  -176,7 +176,7  <at>  <at>  static void jffs2_iset_acl(struct inode *inode, struct posix_acl **i_acl, struct
 	spin_unlock(&inode->i_lock);
 }

-struct posix_acl *jffs2_get_acl(struct inode *inode, int type)
+static struct posix_acl *jffs2_get_acl(struct inode *inode, int type)
 {
 	struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
 	struct posix_acl *acl;
diff --git a/fs/jffs2/acl.h b/fs/jffs2/acl.h
index 76c6ebd..0bb7f00 100644
--- a/fs/jffs2/acl.h
+++ b/fs/jffs2/acl.h
 <at>  <at>  -28,7 +28,6  <at>  <at>  struct jffs2_acl_header {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erez Zadok | 19 Oct 2007 08:05
Picon
Favicon

BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)

David,

I'm testing unionfs on top of jffs2, using 2.6.24 as of linus's commit
4fa4d23fa20de67df919030c1216295664866ad7.  All of my unionfs tests pass when
unionfs is stacked on top of jffs2, other than my truncate test -- whic
tries to truncate files up/down (through the union, which then is passed
through to the lower jffs2 f/s).  The same truncate test passes on all other
file systems I've tried unionfs/2.6.24 with, as well as all of the earlier
kernels that unionfs runs on (2.6.9--2.6.23).  So I tend to think this bug
is more probably due to something else going on in 2.6.24, possibly wrt
jffs2/mtd.  (Of course, it's still possible that unionfs isn't doing
something right -- any pointers?)

The oops trace is included below.  Is this a known issue and if so, any
fixes?  If this is the first you hear of this problem, let me know and I'll
try to narrow it down further.

Thanks,
Erez.

------------[ cut here ]------------
kernel BUG at mm/filemap.c:1749!
invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
Modules linked in: block2mtd mtdblock jffs2 mtd_blkdevs mtd zlib_deflate
zlib_inflate nfsd exportfs auth_rpcgss nfs lockd nfs_acl sunrpc pcnet32
CPU:    0
EIP:    0060:[<c012f03d>]    Not tainted VLI
EFLAGS: 00010287   (2.6.23-unionfs2-2.6.24-rc0-pre #9)
EIP is at iov_iter_advance+0x13/0x5d
eax: c538fdec   ebx: 00001000   ecx: c538fdec   edx: 00001000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Lunz | 30 Aug 2007 20:23

jffs2 deadlock introduced in linux 2.6.22.5


commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between
2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have
introduced another (worse?) one.

With a jffs2 filesystem (on block2mtd) on a 2.6.22.5 kernel, if I do
anything that appends to a file with many small writes, I get what looks
like a deadlock between the writer and the jffs2 gc thread. For example:

	# while true; do echo >> /some/file/on/jffs2; done

will result in the bash hanging in D state, with these kernel stacks in
dmesg after "echo t > /proc/sysrq-trigger":

jffs2_gcd_mtd S DFD1EEA8     0  1086      2 (L-TLB)
       dfd1eebc 00000046 00000002 dfd1eea8 dfd1eea4 00000000 00000000 c0334a00 
       c0334a00 00000000 0000000a dfcb8550 2ee3df10 0000001a 00002280 dfcb8670 
       c1407a00 00000000 00000286 df9fa600 dfe20900 ffff414a c1407ec4 0000ffff 
Call Trace:
 [<c026b84c>] __down_interruptible+0xb2/0x10b
 [<c0269e4b>] __sched_text_start+0x14b/0x8a4
 [<c0115380>] default_wake_function+0x0/0xc
 [<c026b727>] __down_failed_interruptible+0x7/0xc
 [<e09425bd>] jffs2_garbage_collect_pass+0x20/0x597 [jffs2]
 [<c0120cd0>] __dequeue_signal+0xd7/0x11c
 [<c01209ed>] recalc_sigpending+0xb/0x1d
 [<c01221e5>] dequeue_signal+0x9d/0x117
 [<e09439e7>] jffs2_garbage_collect_thread+0x11b/0x15a [jffs2]
 [<c0103bf6>] ret_from_fork+0x6/0x1c
 [<e09438cc>] jffs2_garbage_collect_thread+0x0/0x15a [jffs2]
(Continue reading)

Permalink | Reply | 18 comments |
headers
Joe Perches | 25 Aug 2007 01:44

[PATCH] Prefix each line of multiline printk(KERN_<level> "foo\nbar") with KERN_<level>

Corrected printk calls with multiple output lines which
did not correctly preface each line with KERN_<level>

Fixed uses of some single lines with too many KERN_<level>

Please pull from:
git://repo.or.cz/linux-2.6/trivial-mods.git pr_newlines

Signed-off-by: Joe Perches <joe <at> perches.com>

 arch/arm/kernel/ecard.c                  |    3 ++-
 arch/blackfin/kernel/dualcore_test.c     |    3 ++-
 arch/blackfin/kernel/traps.c             |    4 +++-
 arch/h8300/kernel/setup.c                |    4 +++-
 arch/i386/kernel/io_apic.c               |    3 ++-
 arch/m68knommu/kernel/setup.c            |    4 +++-
 arch/m68knommu/kernel/traps.c            |    5 +++--
 arch/m68knommu/mm/init.c                 |    9 ++++++---
 arch/m68knommu/platform/68328/config.c   |    3 ++-
 arch/m68knommu/platform/68360/config.c   |    3 ++-
 arch/m68knommu/platform/68EZ328/config.c |    3 ++-
 arch/mips/vr41xx/common/pmu.c            |    9 ++++++---
 arch/parisc/kernel/traps.c               |    3 ++-
 arch/parisc/math-emu/driver.c            |    5 +++--
 arch/v850/kernel/setup.c                 |    6 ++++--
 arch/x86_64/kernel/io_apic.c             |    3 ++-
 arch/x86_64/kernel/mpparse.c             |    3 ++-
 drivers/acpi/acpi_memhotplug.c           |    3 ++-
 drivers/char/dtlk.c                      |    3 ++-
 drivers/char/tpm/tpm_bios.c              |    2 +-
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff Layton | 20 Aug 2007 22:53
Picon
Favicon

[PATCH 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correctly

This should fix all of the filesystems in the mainline kernels to handle
ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
just a matter of making sure that they call generic_attrkill early in
the setattr inode op.

Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 arch/powerpc/platforms/cell/spufs/inode.c |    1 +
 fs/9p/vfs_inode.c                         |    1 +
 fs/affs/inode.c                           |    1 +
 fs/afs/inode.c                            |    3 +++
 fs/coda/inode.c                           |    1 +
 fs/configfs/inode.c                       |    4 +++-
 fs/ext2/inode.c                           |    1 +
 fs/ext3/inode.c                           |    5 ++++-
 fs/ext4/inode.c                           |    5 ++++-
 fs/fuse/dir.c                             |    2 ++
 fs/gfs2/ops_inode.c                       |    2 ++
 fs/hostfs/hostfs_kern.c                   |    2 ++
 fs/hpfs/inode.c                           |    1 +
 fs/hugetlbfs/inode.c                      |    5 ++++-
 fs/jffs2/fs.c                             |    1 +
 fs/jfs/acl.c                              |    2 ++
 fs/ocfs2/file.c                           |    2 ++
 fs/proc/base.c                            |    3 +++
 fs/proc/generic.c                         |    3 +++
 fs/proc/proc_sysctl.c                     |    3 +++
 fs/ramfs/file-nommu.c                     |    5 ++++-
 fs/reiserfs/inode.c                       |    6 +++++-
 fs/smbfs/inode.c                          |    2 ++
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeff Layton | 20 Aug 2007 22:53
Picon
Favicon

[PATCH 1/4] VFS: move ATTR_KILL handling from notify_change into helper function

Separate the handling of the local ia_valid bitmask from the one in
attr->ia_valid. This allows us to hand off the actual handling of the
ATTR_KILL_* flags to the .setattr i_op when one is defined.

notify_change still needs to process those flags for the local ia_valid
variable, since it uses that to decide whether to return early, and to pass
a (hopefully) appropriate bitmask to fsnotify_change.

Also, check the ia_valid after the setattr op returns and see if either
ATTR_KILL_* bit is set. If so, then throw a warning and try to clear the
bits in the "standard" way. This should help us to catch filesystems that
don't handle these bits correctly without breaking them outright.

Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/attr.c          |   91 ++++++++++++++++++++++++++++++++++++++++-----------
 include/linux/fs.h |    1 +
 2 files changed, 72 insertions(+), 20 deletions(-)

diff --git a/fs/attr.c b/fs/attr.c
index ae58bd3..50c8ce4 100644
--- a/fs/attr.c
+++ b/fs/attr.c
 <at>  <at>  -100,15 +100,53  <at>  <at>  int inode_setattr(struct inode * inode, struct iattr * attr)
 }
 EXPORT_SYMBOL(inode_setattr);

+/**
+ * generic_attrkill - helper to convert ATTR_KILL_* bits into mode change
+ *  <at> mode: current mode of inode
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Layton | 20 Aug 2007 22:53
Picon
Favicon

[PATCH 0/4] move handling of setuid/gid bits from VFS into individual setattr functions (try 2)

When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.

With a networked filesystem (NFS and CIFS in particular but likely
others), the client machine may not have credentials that allow for
setting the mode. In some situations, this can lead to file corruption,
an operation failing outright because the setattr fails, or to races
that lead to a mode change being reverted.

In this situation, we'd like to just leave the handling of this to the
server and ignore these bits. The problem is that by the time the
setattr op is called, the VFS has already reinterpreted the ATTR_KILL_*
bits into a mode change. We can't fix this in the filesystems where this
is a problem, as doing so would leave us having to second-guess what the
VFS wants us to do. So we need to change it so that filesystems have
more flexibility in how to interpret the ATTR_KILL_* bits.

The first patch in the following patchset moves this logic out of
notify_change and into a helper function. It then has notify_change call
this helper function for inodes that do not have a setattr operation
defined. The other patches fix up the individual filesystems for the new
scheme, mostly by having them call the new helper.

Changing this abruptly could introduce security issues for filesystems
that live out-of-tree or if an in-tree filesystem is missed. As a
precaution, the patchset has notify_change check the ia_valid in the
iattr struct after the setattr call returns. If any ATTR_KILL_* bits are
(Continue reading)

Permalink | Reply | 0 comments |
headers
joe | 13 Aug 2007 08:30

[PATCH] [270/2many] MAINTAINERS - JOURNALLING FLASH FILE SYSTEM V2 (JFFS2)

Add file pattern to MAINTAINER entry

Signed-off-by: Joe Perches <joe <at> perches.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index cbf6cdb..16b6def 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -2584,6 +2584,9  <at>  <at>  M:	dwmw2 <at> infradead.org
 L:	jffs-dev <at> axis.com
 W:	http://sources.redhat.com/jffs2/
 S:	Maintained
+F:	fs/jffs2/
+F:	include/linux/jffs2.h
+F:	include/mtd/jffs2-user.h

 JFS FILESYSTEM
 P:	Dave Kleikamp
Permalink | Reply | 0 comments |
headers
Jeff Layton | 6 Aug 2007 15:54
Picon
Favicon

[PATCH 14/25] JFFS2: call attr_kill_to_mode from jffs2_do_setattr


Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/jffs2/fs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 1d3b7a9..5218f04 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
 <at>  <at>  -37,6 +37,7  <at>  <at>  static int jffs2_do_setattr (struct inode *inode, struct iattr *iattr)
 	uint32_t alloclen;
 	int ret;
 	D1(printk(KERN_DEBUG "jffs2_setattr(): ino #%lu\n", inode->i_ino));
+	attr_kill_to_mode(inode, iattr);
 	ret = inode_change_ok(inode, iattr);
 	if (ret)
 		return ret;
--

-- 
1.5.2.2

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane