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.

-

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
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;

-

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.

-

Yeah, I guess around that time.  If you want, I could go back and test each
Neat.  Curious, but where does "mtd0" come from then?  It's not in my /dev
See below.
> J

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

-

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

`-> __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

-