UBI leb_write_unlock NULL pointer Oops (continuation)

[Ziegler, Emanuel (Lawo AG)]

Hello

We were able to reproduce the error with function trace enabled, and got the following output.
If was too big for pastebin, so i split it into different pastes.

Function Trace Part 1
http://pastebin.com/ugBsJH83
Function Trace Part 2
http://pastebin.com/tBCjLXLj
Function Trace Part 3
http://pastebin.com/FgUZcN4e
Function Trace Part 4
http://pastebin.com/nebyz4XU


>We also were able to reproduce the error with the activated DEBUG_LOCK_ALLOC flag, with the following results.
>
>UBIFS error (pid 7625): ubifs_readdir: cannot find next direntry, error -22
>UBIFS assert failed in ubifs_tnc_next_ent at 2776 (pid 7625)
>[<c001795c>] (unwind_backtrace+0x0/0xf0) from [<c01e0318>] (ubifs_tnc_next_ent+0x18c/0x19c)
>[<c01e0318>] (ubifs_tnc_next_ent+0x18c/0x19c) from [<c01d22d4>] (ubifs_readdir+0x308/0x508)
>[<c01d22d4>] (ubifs_readdir+0x308/0x508) from [<c00d5914>] (vfs_readdir+0x80/0xa4)
>[<c00d5914>] (vfs_readdir+0x80/0xa4) from [<c00d5ad0>] (sys_getdents64+0x64/0xc8)
>[<c00d5ad0>] (sys_getdents64+0x64/0xc8) from [<c0012a20>] (ret_fast_syscall+0x0/0x2c)
>UBIFS error (pid 7625): ubifs_validate_entry: bad extended attribute entry node
>[<c001795c>] (unwind_backtrace+0x0/0xf0) from [<c01dce80>] (lnc_add_directly+0x78/0xc4)
>[<c01dce80>] (lnc_add_directly+0x78/0xc4) from [<c01dcf80>] (matches_name+0xb4/0xcc)
>[<c01dcf80>] (matches_name+0xb4/0xcc) from [<c01dcfd4>] (resolve_collision+0x3c/0x2ec)
>[<c01dcfd4>] (resolve_collision+0x3c/0x2ec) from [<c01e02cc>] (ubifs_tnc_next_ent+0x140/0x19c)
>[<c01e02cc>] (ubifs_tnc_next_ent+0x140/0x19c) from [<c01d22d4>] (ubifs_readdir+0x308/0x508)
>[<c01d22d4>] (ubifs_readdir+0x308/0x508) from [<c00d5914>] (vfs_readdir+0x80/0xa4)
>[<c00d5914>] (vfs_readdir+0x80/0xa4) from [<c00d5ad0>] (sys_getdents64+0x64/0xc8)
>[<c00d5ad0>] (sys_getdents64+0x64/0xc8) from [<c0012a20>] (ret_fast_syscall+0x0/0x2c)
>        magic          0x6101831
>        crc            0x8ae44db2
>        node_type      0 (inode node)
>        group_type     0 (no node group)
>        sqnum          20716
>        len            160
>        key            (954, inode)
>        creat_sqnum    20501
>        size           288
I think the error we seen in the case is related to the following patch and is not related
http://lists.infradead.org/pipermail/linux-mtd/2013-June/047359.html

We port the patches to our Kernel and will try to reproduce it again.


Best Regards
Emanuel