well, my first post here, but: it was really ugly, to find the way, how to subscribe due to there's no link or info at http://aufs.sourceforge.net. maybe this could be changed?
well, this is not always repeatable, but it occures really often, that after mounting aufs next access seems to fail and dmesg shows something like this: [ 1179.190965] BUG: MAX_LOCKDEP_SUBCLASSES too low! [ 1179.191254] turning off the locking correctness validator. [ 1179.191254] Pid: 4092, comm: mkdir Not tainted 2.6.34.6 #2 [ 1179.191254] Call Trace: [ 1179.191254] [<ffffffff81080431>] __lock_acquire+0x481/0xc70 [ 1179.191254] [<ffffffff81080cb1>] lock_acquire+0x91/0x130 [ 1179.307018] [<ffffffffa01121f1>] ? aufs_setattr+0x2d1/0x8c0 [aufs] [ 1179.307018] [<ffffffff8141131e>] ? mutex_lock_nested+0x22e/0x2d0 [ 1179.307018] [<ffffffffa0111a48>] ? au_do_pin+0x128/0x2b0 [aufs] [ 1179.307018] [<ffffffffa0111a48>] ? au_do_pin+0x128/0x2b0 [aufs] [ 1179.307018] [<ffffffff8141113c>] mutex_lock_nested+0x4c/0x2d0 [ 1179.307018] [<ffffffffa01121f1>] ? aufs_setattr+0x2d1/0x8c0 [aufs] [ 1179.307018] [<ffffffffa01121f1>] ? aufs_setattr+0x2d1/0x8c0 [aufs] [ 1179.307018] [<ffffffffa0111aa8>] ? au_do_pin+0x188/0x2b0 [aufs] [ 1179.307018] [<ffffffffa010772c>] ? di_write_lock+0x2c/0x50 [aufs] [ 1179.307018] [<ffffffffa01121f1>] aufs_setattr+0x2d1/0x8c0 [aufs] [ 1179.307018] [<ffffffff810527f7>] ? current_fs_time+0x27/0x30 [ 1179.307018] [<ffffffff8113d7cb>] notify_change+0x16b/0x310 [ 1179.307018] [<ffffffff81123719>] sys_fchmodat+0xd9/0x110 [ 1179.307018] [<ffffffff8141246a>] ? lockdep_sys_exit_thunk+0x35/0x67 [ 1179.307018] [<ffffffff81123768>] sys_chmod+0x18/0x20 [ 1179.307018] [<ffffffff81002f1b>] system_call_fastpath+0x16/0x1b (this occures while mounting multiple trees for a chrooted environment within a script) after that, unmounting isn't possible anymore, but further use seems ok. aufs-version is here: aufs 2-standalone.tree-34-20100823 but it also occures with a 2.6.35.4-kernel and V-35-? ... well, the problem, which occures in kernel/lockdep.c, seems to be solved easily by increasing a value, but a short look at the code has shown, that it's not that easy (at least for me without full knowledge of this locking-behaviour). but maybe someone here has this knowlegde...? any suggestions are welcome... (either help solving the problem or some links about this certain locking-code within the kernel) ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
