[Unionfs] Panic in unionfs 2.2.4

Wed Mar 26 15:44:06 EDT 2008

On Wed, Mar 26, 2008 at 8:20 AM, Erez Zadok <ezk at cs.sunysb.edu> wrote:
>
> In message <2c03f9590803252326p22594f82h99c0a7583681b546 at mail.gmail.com>, "Lucas C. Villa Real" writes:
>  > On Tue, Mar 25, 2008 at 1:42 PM, Erez Zadok <ezk at cs.sunysb.edu> wrote:
>  > > In message <21590311.638981205283907228.JavaMail.root at tahiti.vyatta.com>, Bob Gilligan writes:
>  > >  > Hi Folks -- We're seeing a consistent panic in unionfs 2.2.4 running on
>  > >  > Linux 2.6.23.16.  The panic is due to an assertion failure in dget() in
>  > >  > dcache.h.
>  > >  [...]
>  > >
>  > >  Bob, can you please try unionfs-2.3 (just released) and let me know if you
>  > >  can still tickle this bug?  If so, please open an official Bugzilla report
>  > >  so we can more easily track the bug (the test script you provided would be
>  > >  very helpful).
>  >
>  > For the record, I'm facing exactly the same problem here. I've just
>  > tested with 2.6.24.4 and unionfs 2.3.1. The bug is always
>  > reproducible:
>  >
>  > kernel BUG at include/linux/dcache.h:323!
>  > invalid opcode: 0000 [#1] PREEMPT SMP
>  > Modules linked in: ndiswrapper i915 drm ipv6 snd_pcm_oss snd_mixer_oss
>  > hfsplus joydev appletouch sky2 video i2c_i801 battery output thermal
>  > snd_hda_intel button rtc_cmos rtc_core rtc_lib shpchp ac processor
>  > ohci1394 i2c_core intel_agp iTCO_wdt pci_hotplug snd_pcm snd_timer snd
>  > snd_page_alloc
>  >
>  > Pid: 10131, comm: cp Tainted: P        (2.6.24.4-Gobo #1)
>  > EIP: 0060:[<c10a4d62>] EFLAGS: 00010246 CPU: 1
>  > EIP is at d_alloc+0x172/0x190
>  > EAX: ef583f24 EBX: ef583ee0 ECX: 00000000 EDX: ef583f44
>  > ESI: ef8bb033 EDI: ef583f4e EBP: ef5f1550 ESP: ef80bdd4
>  >  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  > Process cp (pid: 10131, ti=ef80a000 task=ef8fb170 task.ti=ef80a000)
>  > Stack: ef80be38 ef583ee0 ef5f1550 00000000 ef80bf04 ef80be38 c1099f21 ef80be44
>  >        f75cd280 ef5de068 ef5de0e0 ef80be38 ef8bb033 ef5de068 ef8bb029 c109bf02
>  >        ef80bf04 ef8bb029 00000000 00000000 ef192078 c10ea4b4 ef80be80 00000000
>  > Call Trace:
>  >  [<c1099f21>] do_lookup+0x131/0x190
>  >  [<c109bf02>] __link_path_walk+0x7e2/0xdb0
>  >  [<c10ea4b4>] reiserfs_readdir+0x3c4/0x4c0
>  >  [<c109c515>] link_path_walk+0x45/0xc0
>  >  [<c109c778>] do_path_lookup+0x78/0x220
>  >  [<c109b53a>] getname+0x9a/0xf0
>  >  [<c109d1cb>] __user_walk_fd+0x3b/0x60
>  >  [<c1095def>] vfs_lstat_fd+0x1f/0x50
>  >  [<c1095e9f>] sys_lstat64+0xf/0x30
>  >  [<c1093612>] __fput+0x112/0x170
>  >
>  > This have been tested with both reiserfs and ext3 underneath. Do you
>  > have any ideas?
>  >
>  > Thanks,
>  >
>  > --
>  > Lucas
>  > powered by /dev/dsp
>
>  Lucas, I don't see unionfs directly involved in the stack trace above.  Do
>  you have more information?  Can I get a livecd to boot myself, and
>  instructions how to tickle this bug?

This bug happens when union and bind mounts are involved together.
However, I can reproduce the bug reported by Bob, which seems pretty
similar to the one I'm receiving here. I believe they are related to
each other (both panic after assertion fails in dcache.h's dget()).

Running the commands suggested by Bob gives me a slightly different
panic message, though (null pointer):

BUG: unable to handle kernel NULL pointer dereference at virtual
address 0000000f
printing eip: c10a866a *pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ne2k_pci 8390

Pid: 2519, comm: rm Not tainted (2.6.24.4-Gobo #1)
EIP: 0060:[<c10a866a>] EFLAGS: 00000217 CPU: 0
EIP is at __lookup_mnt+0x4a/0x70
EAX: 00000007 EBX: 00000001 ECX: 00000009 EDX: c7805dc8
ESI: c7acbb80 EDI: c76f9330 EBP: c6e79e38 ESP: c6e79dc4
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rm (pid: 2519, ti=c6e78000 task=c6e7d740 task.ti=c6e78000)
Stack: c76f9330 c7acbb80 00000000 c10aa4e6 00000001 c6e79e44 c1099cec c6e79e38
       c76f9330 c6e79f04 c1099e55 c6e79e44 c7acbb80 c1099a7e 019750b8 c6e79e38
       c6dfb00b c740a068 c6dfb001 c109b84a c6e79f04 c6dfb001 00000000 00000000
Call Trace:
 [<c10aa4e6>] lookup_mnt+0x26/0x50
 [<c1099cec>] __follow_mount+0x5c/0x70
 [<c1099e55>] do_lookup+0x65/0x190
 [<c1099a7e>] permission+0x7e/0x160
 [<c109b84a>] __link_path_walk+0x12a/0xdb0
 [<c109c515>] link_path_walk+0x45/0xc0
 [<c109c778>] do_path_lookup+0x78/0x220
 [<c109b53a>] getname+0x9a/0xf0
 [<c109d1cb>] __user_walk_fd+0x3b/0x60
 [<c1095def>] vfs_lstat_fd+0x1f/0x50
 [<c1095f49>] sys_fstatat64+0x29/0x60
 [<c16b3079>] do_page_fault+0x169/0x790
 [<c16b2f10>] do_page_fault+0x0/0x790
 [<c100846e>] sysenter_past_esp+0x6b/0xa1
 =======================
Code: bc 32 8f c1 21 d0 8d 14 c5 00 00 00 00 a1 b8 32 8f c1 01 c2 89
d0 8d 74 26 00 8d bc 27 00 00 00 00 85 db 74 14 8b 00 39 d0 74 18 <3b>
70
08 75 f1 3b 78 0c 75 ec 5b 5e 5f c3 8b 40 04 39 d0 8d 76
EIP: [<c10a866a>] __lookup_mnt+0x4a/0x70 SS:ESP 0068:c6e79dc4
---[ end trace 43dc70afb97a9ff5 ]---
note: rm[2519] exited with preempt_count 1

Thanks,
Lucas