Re: UBI leb_write_unlock NULL pointer Oops (continuation)

[Bill Pringlemeir <bpringlemeir@nbsps.com>]

> Am 21.02.2014 18:53, schrieb Bill Pringlemeir:
>> I don't think the spin_lock() will do anything on a UP system like the
>> ARM926's that have encountered this issue.

On 21 Feb 2014, richard@nod.at wrote:

> Also on UP a spin_lock disables preemption.
> So, le->users is protected.

Thanks, now this make sense...

>   sync-7493    0.... 1348758977us : kmem_cache_alloc_trace <-ltree_add_entry
>   sync-7493    0.... 1348758983us : add_preempt_count <-ltree_add_entry
>   sync-7493    0...1 1348758989us : sub_preempt_count <-ltree_add_entry
>   sync-7493    0.... 1348758994us : kfree <-ltree_add_entry

that those are the spinlocks.  I say some thing dumb and get to learn
something.

It looks like ubi_eba_write_leb() is running retries when this happens
in the pre-empted sync-7493 and then sync-7492 goes in and modifies the
tree and some entries.

If the ltree lock is different than the leb write mutex, could the
'down_write' and 'up_write' use different mutexes?  I guess the 'lnum'
is the same and the 'users' count should prevent this.

I don't see any clues from the function tracing then.

Also, it seems that 'sem->wait_list.next' is NULL and this is in the
space allocated by the 'ltree_entry'.  Ie, the head of the list has
NULL; I was thinking something within the list was NULL.

Regards,
Bill Pringlemeir.