Absolutly reproducable. Running emerge --sync on my tripple aufs tree casues the following kernel crash. I doubt it is caused by Bad ram, as I have ECC memory and edac doesn't mention any error. Could be my mount options of course, no guarantees there. Unmounting my aufs'd tree and syncing directly to one of the targets happens without a problem. [ 1319.470447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [ 1319.470546] IP: [<ffffffffa0059560>] au_diropq_test+0x455/0xa7e [aufs] [ 1319.470622] PGD 21cb40067 PUD 1e2aff067 PMD 0 [ 1319.470685] Oops: 0000 [#1] SMP [ 1319.470738] last sysfs file: /sys/fs/aufs/si_69f00458407abb73/br2 [ 1319.470794] CPU 3 [ 1319.470803] Modules linked in: aufs amd64_edac_mod edac_core mptsas edac_mce_amd mptscsih mptbase [ 1319.470950] [ 1319.470992] Pid: 4924, comm: rsync Not tainted 2.6.36-gentoo-r5 #2 M4A79T Deluxe/System Product Name [ 1319.471085] RIP: 0010:[<ffffffffa0059560>] [<ffffffffa0059560>] au_diropq_test+0x455/0xa7e [aufs] [ 1319.471186] RSP: 0018:ffff880215b95c58 EFLAGS: 00010292 [ 1319.471238] RAX: ffff88021fc15f20 RBX: ffff880215b95e28 RCX: ffff880215b95ce8 [ 1319.471296] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801f82146c0 [ 1319.471355] RBP: ffff880215b95c88 R08: ffff880215b95e28 R09: ffff880215b95db8 [ 1319.471414] R10: ffff880215b95e58 R11: 0000000000000001 R12: 0000000000000002 [ 1319.471472] R13: ffff88021c235e00 R14: ffff8801f80fe4ff R15: ffff8801f82146c0 [ 1319.471532] FS: 00007f0020474700(0000) GS:ffff880001780000(0000) knlGS:0000000000000000 [ 1319.471621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1319.471674] CR2: 0000000000000030 CR3: 0000000215b93000 CR4: 00000000000006e0 [ 1319.471733] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1319.471792] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1319.471851] Process rsync (pid: 4924, threadinfo ffff880215b94000, task ffff88021fcbc380) [ 1319.471938] Stack: [ 1319.471977] ffff880215c9f400 ffff880215b95e28 0000000000000002 ffff88021c235e00 [ 1319.472044] <0> ffff8801f80fe4ff ffff8801f82146c0 ffff880215b95cd8 ffffffffa00599fb [ 1319.472143] <0> ffff880215b95cb8 ffffffff81154b7d ffff8801f8214540 ffff880215b95e28 [ 1319.472273] Call Trace: [ 1319.472328] [<ffffffffa00599fb>] au_diropq_test+0x8f0/0xa7e [aufs] [ 1319.472390] [<ffffffff81154b7d>] ? _atomic_dec_and_lock+0x2d/0x4c [ 1319.472456] [<ffffffffa0062279>] au_wr_dir+0x8f/0x72e [aufs] [ 1319.472519] [<ffffffffa00629dc>] au_may_add+0xc4/0x3a4 [aufs] [ 1319.472584] [<ffffffffa005a49d>] ? di_write_lock+0x1d/0x33 [aufs] [ 1319.472649] [<ffffffffa0062d74>] aufs_mkdir+0xb8/0x312 [aufs] [ 1319.472711] [<ffffffffa0061439>] ? au_pin_init+0xbd/0x243 [aufs] [ 1319.472771] [<ffffffff8109e1c9>] vfs_mkdir+0x44/0x72 [ 1319.472826] [<ffffffff810a079f>] sys_mkdirat+0x94/0xee [ 1319.472880] [<ffffffff81098cd2>] ? sys_newlstat+0x1a/0x3b [ 1319.472936] [<ffffffff810a080c>] sys_mkdir+0x13/0x15 [ 1319.472989] [<ffffffff8100206b>] system_call_fastpath+0x16/0x1b [ 1319.473043] Code: 87 90 00 00 00 48 89 45 d0 48 8b 87 98 00 00 00 48 8b 55 d0 44 8a 70 28 48 8b 82 70 02 00 00 49 0f be d6 48 8b 40 78 48 8b 14 d0 <48> 8b 42 30 48 8b 40 28 f6 40 50 01 75 15 8b 42 2c 85 c0 74 05 [ 1319.473429] RIP [<ffffffffa0059560>] au_diropq_test+0x455/0xa7e [aufs] [ 1319.473496] RSP <ffff880215b95c58> [ 1319.473540] CR2: 0000000000000030 [ 1319.474099] ---[ end trace 37056c2f86871371 ]--- /proc/mounts /dev/md101 /tank/01 ext4 rw,noatime,commit=120,barrier=1,stripe=192,data=writeback 0 0 /dev/md102 /tank/02 ext4 rw,noatime,commit=120,barrier=1,stripe=256,data=writeback 0 0 /dev/md103 /tank/03 ext4 rw,noatime,commit=120,barrier=1,stripe=192,data=writeback 0 0 none /silo aufs rw,relatime,si=2a568c815c84ee87,udba=none,create=pmfs,cpup=bup,sum 0 0 cat: /sys/module/aufs/holders: Is a directory live cat: /sys/module/aufs/notes: Is a directory cat: /sys/module/aufs/parameters: Is a directory 0 cat: /sys/module/aufs/sections: Is a directory 9A243B57E512A94D36FD5FB 2.1-standalone.tree-36-20110117 riley ~ # cat /sys/fs/aufs/si_2a568c815cba1e87/* /tank/01=rw /tank/02=rw /tank/03=rw /tank/01/.aufs.xino On 02/09/11 10:21, Oliver Schinagl wrote:
I'm not sure if I'm having the same issue, but after running emerge --sync (e.g. rsync from the gentoo repository to my local aufs'd tree) my system locks too. Can't unmount my aufs'd tree either. I should have copy/pasted my dmesg the system was so hung, I had to power cycle it. I'm using the following module/kernel version on my gentoo box. I'm a little scared to retry this after a reboot, but i might just have to :S filename: /lib/modules/2.6.36-gentoo-r5/misc/aufs.ko version: 2.1-standalone.tree-36-20110117 On 02/09/11 10:06, Ken Park wrote: I am exploring stacking an AFS filesystem with a local filesystem, under Ubuntu Maverick. AFS_PATH='path to afs directory of interest' mkdir aumnt mount -t aufs -o dirs=$AFS_PATH aufs aumnt cd aumnt echo "hello world" > hw ln -s hw ln_hw Everything succeeds until that last ln command, which outputs "Killed", as confirmed by exit code of 137. Afterwards, ls, lsof, or any attempt to access aumnt leads bash to hang. It cannot be unmounted, either. If I try to access the AFS_PATH directly, outside of the aufs mount, it also hangs when I try to access that particular directory. The only way I've been able to regain access to AFS_PATH is by reboot, at which point I see that the ln command actually HAS been successful. There is a symlink there for file hw. The above is an example of just one branch, but a union with a local branch leads to same thing if the writable branch is the AFS branch. Making a symlink to an AFS file on the local filesystem is OK. What could be going on here? Thanks for any help. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. [1][1]http://p.sf.net/sfu/intel-dev2devfeb References 1. [2]http://p.sf.net/sfu/intel-dev2devfeb ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. [3]http://p.sf.net/sfu/intel-dev2devfeb References 1. http://p.sf.net/sfu/intel-dev2devfeb 2. http://p.sf.net/sfu/intel-dev2devfeb 3. http://p.sf.net/sfu/intel-dev2devfeb
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
