AW: AW: UBI leb_write_unlock NULL pointer Oops (continuation)

[Quiniou, Benoit (Lawo AG)]

> The part of the first trace fits in one paste:
> 
> http://pastebin.com/TL3yNVcw
> 
> The part of the second trace is bigger than 500k, so split into two pastes.
> 
> http://pastebin.com/1qMt0Pqg
> http://pastebin.com/ZLXU17wx
> 
> We'll have a closer look at that.
> 
> Regards,
> Thorsten

Hello mtd-linux mailing list,

My name is Benoit and I work together with Thorsten and Emanuel on this.
Eventhought  I am not a kernel expert, I try to take a deep look in the 2 ftraces we've got, in order to find differences and similarities and maybe have a clue what happened differently in the failed operations.
I put my efforts looking at what happens between leb_write_lock and leb_write_unlock all over the traces (not only the partial traces commited to pastebin).
What I can already tell, is that in both traces, I can see ubifs_orphan_ operations in very similar ways and only once in each traces :
1- 1 process invokes ubifs_add_orphan
... some processes invoke ubifs api...
2- 1 other process (a sync) invokes ubifs_oprhan_start_commit
... some processes invoke ubifs api...
3- a third process invokes ubifs_delete_orphan
... some processes invoke ubifs api...
4- the process in which the failure finally arises invokes leb_write_lock 
(starting from here you can follow the trace in first pastebin, line 112)
... some processes invoke ubifs api...
5- sync process of 2- invokes ubifs_orphan_end_commit (line 614) and gets interrupted by other processes before it finishes (line 734 and several processes after that point). This process resumes at line 2336
... some processes invoke ubifs api in the meanwhile...
6- failing process finally comes to leb_write_unlock (line 4332) and goes to the Oops.

I will continue to take deep look at traces to see if I find things more closely related to the semaphore you pointed out.

Regards,

Benoit Quiniou