Thayumanavar Sachithanantham:
> The kernel is 2.6.27.45 SLES kernel with aufs ( recent ver as taken
> git for 2.6.27) pulled into it.

How recent is it?
For instance, I made some bugfixes recently. Do you think they are
related to your problem?

4946ca0 2010-07-21 aufs: bugfix, buffer overrun in au_whtmp_lkup()
068b8fe 2010-07-20 aufs: bugfix, un-static a local var in dy_get()
4de8d40 2010-07-20 aufs: Fix null pointer dereference on branch deletion
396a2f0 2010-06-29 aufs: bugfix, separate the workqueue for preprocessing mmap
135ac88 2010-06-20 aufs: possible bugfix, sbinfo lock in deleting inode, lockdep
6ef8250 2010-06-20 aufs: possible bugfix, sbinfo lock in deleting inode, core
eb6254f 2010-06-20 aufs: possible bugfix, sbinfo lock in deleting inode, use 
si_pid
89d5929 2010-06-16 aufs: possible bugfix, sbinfo lock in deleting inode, si_pid 
functions
40d554b 2010-06-16 aufs: possible bugfix, sbinfo lock in deleting inode, __si_ 
lock


> The test cases involves creating parallel threads ( that does file
> creation (using dd), mkdir, unlink and rename) and a parallel script
> that tries do
> branch deletion contiuously in a loop until we succed to delete a
> branch ( when no EBUSY comes up).

Interesting.
I will try such test when I have time.


> Here is the backtrace and diassembly for the crash:
> [ from diassembly it appear that deref of h_inode->i_count in
> au_h_iptr led to crash).
        :::
> =A0 =A0[exception RIP: au_h_iptr+69]
        :::
> =A0 =A0RAX: 00000000000000a5 =A0RBX: ffffffff8020bfcb =A0RCX: ffffffffc0ed0=
        :::
> 0xffffffffa02a777d <au_h_iptr+69>: =A0 =A0 =A0cmpl =A0 $0x0,0x48(%rax)

Let me make sure.
Does it compare the contents of (0xa5 + 0x48) with zero?
Probably you already confirmed that 0x48 is the offset of i_count, and
RAX is h_inode which is broken 0xa5. Is this what you are thinking?


J. R. Okajima

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 

Reply via email to