[Unionfs] Panic in unionfs 2.2.4

Bob Gilligan gilligan at vyatta.com
Tue Mar 11 21:05:07 EDT 2008


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.

The following sequence of commands, which involves mounting and unmounting a unionfs over a tmpfs, reproduces the panic:

mkdir -p /tmpfs_mnt
mount -t tmpfs none /tmpfs_mnt
mkdir -p /tmpfs_mnt/active
mkdir -p /tmpfs_mnt/tmp/new
mkdir -p /tmpfs_mnt/tmp/changes
mount -t unionfs -o dirs=/tmpfs_mnt/tmp/changes=rw:/tmpfs_mnt/active=ro unionfs /tmpfs_mnt/tmp/new

mkdir -p /tmpfs_mnt/tmp/new/x/y

rm -rf /tmpfs_mnt/tmp/copy
cp -r -f /tmpfs_mnt/tmp/new /tmpfs_mnt/tmp/copy
umount /tmpfs_mnt/tmp/new
rm -rf /tmpfs_mnt/tmp/changes
mkdir -p /tmpfs_mnt/tmp/changes
rm -rf /tmpfs_mnt/active
cp -rp /tmpfs_mnt/tmp/copy /tmpfs_mnt/active
rm -rf /tmpfs_mnt/tmp/copy
mount -t unionfs -o dirs=/tmpfs_mnt/tmp/changes=rw:/tmpfs_mnt/active=ro unionfs /tmpfs_mnt/tmp/new

rm -rf /tmpfs_mnt/tmp/new/x/y

rm -rf /tmpfs_mnt/tmp/copy
cp -r -f /tmpfs_mnt/tmp/new /tmpfs_mnt/tmp/copy
umount /tmpfs_mnt/tmp/new
rm -rf /tmpfs_mnt/tmp/changes


The panic signature is:

------------[ cut here ]------------
kernel BUG at include/linux/dcache.h:322!
invalid opcode: 0000 [#1]
SMP
Modules linked in: ppp_async crc_ccitt af_packet ppp_generic slhc unionfs xt_NOTRACK iptable_raw ip_tables nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_h323 nf_conntrack_h323 nf_nat_sip nf_conntrack_sip nf_nat_proto_gre nf_nat_tftp nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink ipt_rlsnmpstats x_tables ipv6 capability commoncap xfrm_user xfrm4_tunnel tunnel4 ipcomp esp4 ah4 deflate zlib_deflate twofish twofish_common serpent aes blowfish des cbc ecb blkcipher sha256 sha1 crypto_null af_key evdev i2c_viapro i2c_core pcspkr via_agp shpchp agpgart pci_hotplug ext3 jbd mbcache ehci_hcd sata_via uhci_hcd 8139cp libata floppy scsi_mod via82cxxx generic 8139too mii usbcore ide_disk
CPU:    0
EIP:    0060:[<c0171568>]    Not tainted VLI
EFLAGS: 00010246   (2.6.23-1-486-vyatta #1)
EIP is at __follow_mount+0x68/0x70
eax: 00000000   ebx: df7f38c0   ecx: 00000000   edx: d94ce5b8
esi: d9547eac   edi: 00000000   ebp: d9547ea0   esp: d9547e3c
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process rm (pid: 5027, ti=d9546000 task=df100550 task.ti=d9546000)
Stack: 00000000 d94cef00 d9547f54 c01716c7 d9547eac df7f3e40 00000001 c017132a
       d9547ea0 0bc9d0c5 de9d800b df470c44 c017304c c01684a2 00098801 d9547f54
       de9d8001 00000010 ffffff9c d9547f30 de9d8000 c0174023 df58cd40 c016b3bf
Call Trace:
 [<c01716c7>] do_lookup+0x67/0x1a0
 [<c017132a>] permission+0xfa/0x110
 [<c017304c>] __link_path_walk+0x12c/0xe20
 [<c01684a2>] get_unused_fd_flags+0x52/0xd0
 [<c0174023>] do_path_lookup+0x73/0x1b0
 [<c016b3bf>] get_empty_filp+0x6f/0x150
 [<c0173d85>] link_path_walk+0x45/0xc0
 [<c016bdd4>] deactivate_super+0x14/0x80
 [<c01697ca>] sys_fchdir+0x4a/0x90
 [<c0174023>] do_path_lookup+0x73/0x1b0
 [<c0172c27>] getname+0xa7/0xc0
 [<c017463f>] do_rmdir+0x3f/0xe0
 [<c016bdd4>] deactivate_super+0x14/0x80
 [<c01697ca>] sys_fchdir+0x4a/0x90
 [<c01042c2>] syscall_call+0x7/0xb
 =======================
Code: 8b 02 85 c0 74 25 90 ff 02 89 56 04 8b 42 5c bf 01 00 00 00 85 c0 74 0d 8b 06 e8 64 00 01 00 85 c0 89 c3 75 b1 89 f8 5b 5e 5f c3 <0f> 0b eb fe 8d 74 26 00 57 39 d0 56 89 c7 53 89 d6 74 7b 8b 40
EIP: [<c0171568>] __follow_mount+0x68/0x70 SS:ESP 0068:d9547e3c
Kernel panic - not syncing: Fatal exception
Rebooting in 60 seconds..

The assertion in dget() has to do with the dentry refcount:

static inline struct dentry *dget(struct dentry *dentry)
{
        if (dentry) {
                BUG_ON(!atomic_read(&dentry->d_count));
                atomic_inc(&dentry->d_count);
        }
        return dentry;
}


Is anyone else seeing this problem?

Bob.


More information about the unionfs mailing list