Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 20:31:29 +0200, Peter Zijlstra wrote: > > > > BUG: key f88e1340 not in .data! > > WARNING: at kernel/lockdep.c:2331 lockdep_init_map() > > [] show_trace_log_lvl+0x1a/0x2f > > [] show_trace+0x12/0x14 > > [] dump_stack+0x15/0x17 > > [] lockdep_init_map+0x94/0x3e4 > > [] debug_mutex_init+0x2c/0x3c > > [] __mutex_init+0x38/0x40 > > [] 0xf88e01d3 > > [] parse_args+0x123/0x200 > > [] sys_init_module+0xdd0/0x122c > > [] sysenter_past_esp+0x5f/0x91 > > === > > block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] > > block2mtd: version $Revision: 1.30 $ > > Someone stuck a key object in non static storage. That breaks lockdep, > don't do that :-) > > Is the mutex_init() done from a function tagged with __init? Root cause is an ordering problem in module loading. Code flow is roughly this: sys_init_module `-> load_module : `-> parse_args : `-> block2mtd_setup : `-> __mutex_init : `-> lockdep_init_map : `-> static_obj : `-> is_module_address `-> __link_module is_module_address() would return something sane, if __link_module() had already been called. In fact, if the parameter is passed through /sys/modules/block2mtd/parameters/block2mtd _after_ module load time, the exact same code works fine. Only when passing the parameter as a module parameter do we see this problem. So what should be done? We could move parse_args() below __link_module(), but I'd guess such a change would break some other modules what depend on certain parameters or at least should fail to load with illegal parameters. Do such modules exist? Or we could add some kind of parse_args_late() that is called after __link_module(), if requested by a module, and annotate block2mtd to prefer that version. [ Adding Ingo on Cc:. Since block2mtd predates lockdep I found a bug in his code and not the other way around. ;) ] Jörn -- Do not stop an army on its way home. -- Sun Tzu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 20:31:29 +0200, Peter Zijlstra wrote: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [c0102bc2] show_trace_log_lvl+0x1a/0x2f [c0103692] show_trace+0x12/0x14 [c01037b2] dump_stack+0x15/0x17 [c0125432] lockdep_init_map+0x94/0x3e4 [c0125001] debug_mutex_init+0x2c/0x3c [c01210d4] __mutex_init+0x38/0x40 [f88e01d3] 0xf88e01d3 [c011dda7] parse_args+0x123/0x200 [c012b725] sys_init_module+0xdd0/0x122c [c0102586] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ Someone stuck a key object in non static storage. That breaks lockdep, don't do that :-) Is the mutex_init() done from a function tagged with __init? Root cause is an ordering problem in module loading. Code flow is roughly this: sys_init_module `- load_module : `- parse_args : `- block2mtd_setup : `- __mutex_init : `- lockdep_init_map : `- static_obj : `- is_module_address `- __link_module is_module_address() would return something sane, if __link_module() had already been called. In fact, if the parameter is passed through /sys/modules/block2mtd/parameters/block2mtd _after_ module load time, the exact same code works fine. Only when passing the parameter as a module parameter do we see this problem. So what should be done? We could move parse_args() below __link_module(), but I'd guess such a change would break some other modules what depend on certain parameters or at least should fail to load with illegal parameters. Do such modules exist? Or we could add some kind of parse_args_late() that is called after __link_module(), if requested by a module, and annotate block2mtd to prefer that version. [ Adding Ingo on Cc:. Since block2mtd predates lockdep I found a bug in his code and not the other way around. ;) ] Jörn -- Do not stop an army on its way home. -- Sun Tzu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 16:04:10 -0400, Erez Zadok wrote: > In message <[EMAIL PROTECTED]>, =?utf-8?B?SsO2cm4=?= Engel writes: > > > > Since when roughly? 2.6.20ish? Before? > > Yeah, I guess around that time. If you want, I could go back and test each > of my backports and see if it has the lockdep message or not. That's ok. Just wanted to get a rough idea. > > Side note: you don't need mtdblock: > > # cp jffs2-empty.img /tmp/foo > > # losetup /dev/loop0 /tmp/foo > > # modprobe block2mtd block2mtd=/dev/loop0,128ki > > # mount -t jffs2 mtd0 /n/lower/b0 > > > > It doesn't really hurt, 'tis just superfluous. > > Neat. Curious, but where does "mtd0" come from then? It's not in my /dev > (which uses devfs on an FC6 system). JFFS2 interprets that itself. The only reason why JFFS2 needed a block device was to determine the minor number of the mtd underneith. So code was added to find the correct mtd from "mtd0" or "mtd:some_name" instead. I believe you can even disable CONFIG_BLOCK now. And the code itself was moved to drivers/mtd/mtdsuper.c fairly recently. Jörn -- Joern's library part 2: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 16:04:10 -0400, Erez Zadok wrote: In message [EMAIL PROTECTED], =?utf-8?B?SsO2cm4=?= Engel writes: Since when roughly? 2.6.20ish? Before? Yeah, I guess around that time. If you want, I could go back and test each of my backports and see if it has the lockdep message or not. That's ok. Just wanted to get a rough idea. Side note: you don't need mtdblock: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 mtd0 /n/lower/b0 It doesn't really hurt, 'tis just superfluous. Neat. Curious, but where does mtd0 come from then? It's not in my /dev (which uses devfs on an FC6 system). JFFS2 interprets that itself. The only reason why JFFS2 needed a block device was to determine the minor number of the mtd underneith. So code was added to find the correct mtd from mtd0 or mtd:some_name instead. I believe you can even disable CONFIG_BLOCK now. And the code itself was moved to drivers/mtd/mtdsuper.c fairly recently. Jörn -- Joern's library part 2: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
In message <[EMAIL PROTECTED]>, =?utf-8?B?SsO2cm4=?= Engel writes: > On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: > > > > I've been having this problem for some time with mtd, which I use to mount > > jffs2 images (for unionfs testing). I've seen it in several recent major > > kernels, including 2.6.24. Here's the sequence of ops I perform: > > Since when roughly? 2.6.20ish? Before? I was able to verify that the same lockdep warning comes up in every major kernel all the way back to 2.6.18. Of course the line number in lockdep.c that causes the warning is slightly different from kernel to kernel, but the stack trace is the same. Hope this helps. Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
In message <[EMAIL PROTECTED]>, =?utf-8?B?SsO2cm4=?= Engel writes: > On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: > > > > I've been having this problem for some time with mtd, which I use to mount > > jffs2 images (for unionfs testing). I've seen it in several recent major > > kernels, including 2.6.24. Here's the sequence of ops I perform: > > Since when roughly? 2.6.20ish? Before? Yeah, I guess around that time. If you want, I could go back and test each of my backports and see if it has the lockdep message or not. > > # cp jffs2-empty.img /tmp/foo > > # losetup /dev/loop0 /tmp/foo > > # modprobe mtdblock > > # modprobe block2mtd block2mtd=/dev/loop0,128ki > > # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 > > Side note: you don't need mtdblock: > # cp jffs2-empty.img /tmp/foo > # losetup /dev/loop0 /tmp/foo > # modprobe block2mtd block2mtd=/dev/loop0,128ki > # mount -t jffs2 mtd0 /n/lower/b0 > > It doesn't really hurt, 'tis just superfluous. Neat. Curious, but where does "mtd0" come from then? It's not in my /dev (which uses devfs on an FC6 system). > > The jffs2-empty.img is a small jffs2 image, of an empty directory, created > > w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following > > lockdep warning and a "BUG" message: > > > > BUG: key f88e1340 not in .data! > > WARNING: at kernel/lockdep.c:2331 lockdep_init_map() > > [] show_trace_log_lvl+0x1a/0x2f > > [] show_trace+0x12/0x14 > > [] dump_stack+0x15/0x17 > > [] lockdep_init_map+0x94/0x3e4 > > [] debug_mutex_init+0x2c/0x3c > > [] __mutex_init+0x38/0x40 > > [] 0xf88e01d3 > > [] parse_args+0x123/0x200 > > [] sys_init_module+0xdd0/0x122c > > [] sysenter_past_esp+0x5f/0x91 > > === > > block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] > > block2mtd: version $Revision: 1.30 $ > > Could be my problem. I'll see if I can reproduce it. Can you send me > your .config or a link to it? See below. > Jörn > > -- > /* Keep these two variables together */ > int bar; Thanks, Erez. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Fri Oct 19 00:28:55 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: > > I've been having this problem for some time with mtd, which I use to mount > jffs2 images (for unionfs testing). I've seen it in several recent major > kernels, including 2.6.24. Here's the sequence of ops I perform: Since when roughly? 2.6.20ish? Before? > # cp jffs2-empty.img /tmp/foo > # losetup /dev/loop0 /tmp/foo > # modprobe mtdblock > # modprobe block2mtd block2mtd=/dev/loop0,128ki > # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 Side note: you don't need mtdblock: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 mtd0 /n/lower/b0 It doesn't really hurt, 'tis just superfluous. > The jffs2-empty.img is a small jffs2 image, of an empty directory, created > w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following > lockdep warning and a "BUG" message: > > BUG: key f88e1340 not in .data! > WARNING: at kernel/lockdep.c:2331 lockdep_init_map() > [] show_trace_log_lvl+0x1a/0x2f > [] show_trace+0x12/0x14 > [] dump_stack+0x15/0x17 > [] lockdep_init_map+0x94/0x3e4 > [] debug_mutex_init+0x2c/0x3c > [] __mutex_init+0x38/0x40 > [] 0xf88e01d3 > [] parse_args+0x123/0x200 > [] sys_init_module+0xdd0/0x122c > [] sysenter_past_esp+0x5f/0x91 > === > block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] > block2mtd: version $Revision: 1.30 $ Could be my problem. I'll see if I can reproduce it. Can you send me your .config or a link to it? Jörn -- /* Keep these two variables together */ int bar; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 2007-10-19 at 13:53 -0400, Erez Zadok wrote: > I've been having this problem for some time with mtd, which I use to mount > jffs2 images (for unionfs testing). I've seen it in several recent major > kernels, including 2.6.24. Here's the sequence of ops I perform: > > # cp jffs2-empty.img /tmp/foo > # losetup /dev/loop0 /tmp/foo > # modprobe mtdblock > # modprobe block2mtd block2mtd=/dev/loop0,128ki > # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 > > The jffs2-empty.img is a small jffs2 image, of an empty directory, created > w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following > lockdep warning and a "BUG" message: > > BUG: key f88e1340 not in .data! > WARNING: at kernel/lockdep.c:2331 lockdep_init_map() > [] show_trace_log_lvl+0x1a/0x2f > [] show_trace+0x12/0x14 > [] dump_stack+0x15/0x17 > [] lockdep_init_map+0x94/0x3e4 > [] debug_mutex_init+0x2c/0x3c > [] __mutex_init+0x38/0x40 > [] 0xf88e01d3 > [] parse_args+0x123/0x200 > [] sys_init_module+0xdd0/0x122c > [] sysenter_past_esp+0x5f/0x91 > === > block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] > block2mtd: version $Revision: 1.30 $ > > However, everything seems to work afterwards: jffs2 mounts, and all my > unionfs+jffs2 tests succeed. > > So, what is this "key xxx not in .data" message and should I worry? Is the > lockdep warning a problem? (It might be a problem if lockdep warnings are > turned off afterwards, so lockdep won't complain about future warnings.) > Heck, am I using mtd/jffs correctly? Someone stuck a key object in non static storage. That breaks lockdep, don't do that :-) Is the mutex_init() done from a function tagged with __init? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe mtdblock # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 The jffs2-empty.img is a small jffs2 image, of an empty directory, created w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following lockdep warning and a "BUG" message: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x15/0x17 [] lockdep_init_map+0x94/0x3e4 [] debug_mutex_init+0x2c/0x3c [] __mutex_init+0x38/0x40 [] 0xf88e01d3 [] parse_args+0x123/0x200 [] sys_init_module+0xdd0/0x122c [] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ However, everything seems to work afterwards: jffs2 mounts, and all my unionfs+jffs2 tests succeed. So, what is this "key xxx not in .data" message and should I worry? Is the lockdep warning a problem? (It might be a problem if lockdep warnings are turned off afterwards, so lockdep won't complain about future warnings.) Heck, am I using mtd/jffs correctly? Thanks, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: Since when roughly? 2.6.20ish? Before? # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe mtdblock # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 Side note: you don't need mtdblock: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 mtd0 /n/lower/b0 It doesn't really hurt, 'tis just superfluous. The jffs2-empty.img is a small jffs2 image, of an empty directory, created w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following lockdep warning and a BUG message: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [c0102bc2] show_trace_log_lvl+0x1a/0x2f [c0103692] show_trace+0x12/0x14 [c01037b2] dump_stack+0x15/0x17 [c0125432] lockdep_init_map+0x94/0x3e4 [c0125001] debug_mutex_init+0x2c/0x3c [c01210d4] __mutex_init+0x38/0x40 [f88e01d3] 0xf88e01d3 [c011dda7] parse_args+0x123/0x200 [c012b725] sys_init_module+0xdd0/0x122c [c0102586] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ Could be my problem. I'll see if I can reproduce it. Can you send me your .config or a link to it? Jörn -- /* Keep these two variables together */ int bar; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
In message [EMAIL PROTECTED], =?utf-8?B?SsO2cm4=?= Engel writes: On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: Since when roughly? 2.6.20ish? Before? I was able to verify that the same lockdep warning comes up in every major kernel all the way back to 2.6.18. Of course the line number in lockdep.c that causes the warning is slightly different from kernel to kernel, but the stack trace is the same. Hope this helps. Erez. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe mtdblock # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 The jffs2-empty.img is a small jffs2 image, of an empty directory, created w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following lockdep warning and a BUG message: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [c0102bc2] show_trace_log_lvl+0x1a/0x2f [c0103692] show_trace+0x12/0x14 [c01037b2] dump_stack+0x15/0x17 [c0125432] lockdep_init_map+0x94/0x3e4 [c0125001] debug_mutex_init+0x2c/0x3c [c01210d4] __mutex_init+0x38/0x40 [f88e01d3] 0xf88e01d3 [c011dda7] parse_args+0x123/0x200 [c012b725] sys_init_module+0xdd0/0x122c [c0102586] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ However, everything seems to work afterwards: jffs2 mounts, and all my unionfs+jffs2 tests succeed. So, what is this key xxx not in .data message and should I worry? Is the lockdep warning a problem? (It might be a problem if lockdep warnings are turned off afterwards, so lockdep won't complain about future warnings.) Heck, am I using mtd/jffs correctly? Thanks, Erez. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
On Fri, 2007-10-19 at 13:53 -0400, Erez Zadok wrote: I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe mtdblock # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 The jffs2-empty.img is a small jffs2 image, of an empty directory, created w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following lockdep warning and a BUG message: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [c0102bc2] show_trace_log_lvl+0x1a/0x2f [c0103692] show_trace+0x12/0x14 [c01037b2] dump_stack+0x15/0x17 [c0125432] lockdep_init_map+0x94/0x3e4 [c0125001] debug_mutex_init+0x2c/0x3c [c01210d4] __mutex_init+0x38/0x40 [f88e01d3] 0xf88e01d3 [c011dda7] parse_args+0x123/0x200 [c012b725] sys_init_module+0xdd0/0x122c [c0102586] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ However, everything seems to work afterwards: jffs2 mounts, and all my unionfs+jffs2 tests succeed. So, what is this key xxx not in .data message and should I worry? Is the lockdep warning a problem? (It might be a problem if lockdep warnings are turned off afterwards, so lockdep won't complain about future warnings.) Heck, am I using mtd/jffs correctly? Someone stuck a key object in non static storage. That breaks lockdep, don't do that :-) Is the mutex_init() done from a function tagged with __init? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
In message [EMAIL PROTECTED], =?utf-8?B?SsO2cm4=?= Engel writes: On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote: I've been having this problem for some time with mtd, which I use to mount jffs2 images (for unionfs testing). I've seen it in several recent major kernels, including 2.6.24. Here's the sequence of ops I perform: Since when roughly? 2.6.20ish? Before? Yeah, I guess around that time. If you want, I could go back and test each of my backports and see if it has the lockdep message or not. # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe mtdblock # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 /dev/mtdblock0 /n/lower/b0 Side note: you don't need mtdblock: # cp jffs2-empty.img /tmp/foo # losetup /dev/loop0 /tmp/foo # modprobe block2mtd block2mtd=/dev/loop0,128ki # mount -t jffs2 mtd0 /n/lower/b0 It doesn't really hurt, 'tis just superfluous. Neat. Curious, but where does mtd0 come from then? It's not in my /dev (which uses devfs on an FC6 system). The jffs2-empty.img is a small jffs2 image, of an empty directory, created w/ the jffs2 utils. At the point I modprobe block2mtd, I get the following lockdep warning and a BUG message: BUG: key f88e1340 not in .data! WARNING: at kernel/lockdep.c:2331 lockdep_init_map() [c0102bc2] show_trace_log_lvl+0x1a/0x2f [c0103692] show_trace+0x12/0x14 [c01037b2] dump_stack+0x15/0x17 [c0125432] lockdep_init_map+0x94/0x3e4 [c0125001] debug_mutex_init+0x2c/0x3c [c01210d4] __mutex_init+0x38/0x40 [f88e01d3] 0xf88e01d3 [c011dda7] parse_args+0x123/0x200 [c012b725] sys_init_module+0xdd0/0x122c [c0102586] sysenter_past_esp+0x5f/0x91 === block2mtd: mtd0: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ Could be my problem. I'll see if I can reproduce it. Can you send me your .config or a link to it? See below. Jörn -- /* Keep these two variables together */ int bar; Thanks, Erez. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Fri Oct 19 00:28:55 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set
