[Unionfs] Panic in unionfs 2.2.4

Wed Mar 26 20:58:56 EDT 2008

----- "Lucas C. Villa Real" <lucasvr at gobolinux.org> wrote:
> 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

And I see the panic too in unionfs-2.3.1 running on our 2.6.23 kernel.  It is the same panic signature as before:  BUG at include/linux/dcache.h:322

I've filed a bug report on the problem:

https://bugzilla.filesystems.org/show_bug.cgi?id=611

Bob.