UBI leb_write_unlock NULL pointer Oops (continuation)

[Bill Pringlemeir]

>> 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 at nod.at wrote:

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

On 21 Feb 2014, bpringlemeir at nbsps.com wrote:

> Thanks, now this make sense...

[snip]

> 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.

I think the 'ubi_eba_copy_leb()' may have an issue.

int ubi_eba_copy_leb(struct ubi_device *ubi, int from, int to,
		     struct ubi_vid_hdr *vid_hdr)
{
...

	err = leb_write_trylock(ubi, vol_id, lnum);

static int leb_write_trylock(struct ubi_device *ubi, int vol_id, int lnum)
{
..
	le = ltree_add_entry(ubi, vol_id, lnum);  /* users + 1 */
	if (IS_ERR(le))
		return PTR_ERR(le);
	if (down_write_trylock(&le->mutex))
		return 0;

	/* Contention, cancel */
	spin_lock(&ubi->ltree_lock);
	le->users -= 1;                           /* user - 1 */
...
	spin_unlock(&ubi->ltree_lock);           

	return 1;
}

	if (err)...

	if (vol->eba_tbl[lnum] != from) {
		dbg_wl("LEB %d:%d is no longer mapped to PEB %d, mapped to PEB %d, cancel",
		       vol_id, lnum, from, vol->eba_tbl[lnum]);
		err = MOVE_CANCEL_RACE;
		goto out_unlock_leb;
	}
...
out_unlock_leb:
	leb_write_unlock(ubi, vol_id, lnum);     /* user - 1 */


Didn't the count have to bump up in this case?  This isn't in Thorsten's
traces, but neither are any 'down_read' or 'up_read' traces; maybe
everything is in cache?

Regards,
Bill Pringlemeir.