UBI leb_write_unlock NULL pointer Oops (continuation)

Bill Pringlemeir bpringlemeir at nbsps.com
Fri Feb 14 12:11:30 EST 2014


> Am 12.02.2014 19:21, schrieb Bill Pringlemeir:

>> Does that sound right Richard?  Will it matter if I use a fixed or
>> dynamic volume size?  Can I make a small UBI/UbiFS MTD partition and use
>> that for testing?  My dynamic partition is about 200MB big.  Usually we
>> never come near filling it, so there is lots of opportunity to use other
>> erase blocks.

On 12 Feb 2014, richard at nod.at wrote:

> Yeah, I had the same idea and setup a MTD using nandsim.
> So far I was unable to trigger the issue.

> Let's wait for more results from Thorsten.

Ok, but I would like to try with one of my ARM926 systems.  I think that
this is not a simple race.  In rwsem-spinlock.c there are two places
where 'rwsem_waiter' are 'allocated'.  Those are '__down_read' and
'__down_write_nested'.  The 'rwsem_waiter' is allocated on the kernel
stack and the current task is halted.  This is patched into the list of
the 'rwsem' rooted in ubi's ubi_ltree_entry.  Ie, the list 'allocation'
are across various task's thread_info.

If a task is killed and/or the 'sp' is not in a good state, we may be a
weird value linked in the 'rwsem' list.  On the ARM926, there are no
lock free primitives except 'swp' and in order to RMW the platform locks
interrupts.  However, UbiFS/UBI maybe called via a data fault handler
and these can not be locked.  If this is the case, you will never be
able to replicate it on anything but an ARM926 or an architecture with
this type of atomic primitives.  This is why I was originally cross
posting to the ARM list.

I think having a better test case would be constructive?  At least we
should explore the fact that it is an 'arch dependent' issue?  All of
the cases reported seem to be confined to the ARM926.

It seems like many readers/writer to a small UBI partition would be the
best type of test case.  I am not sure if UbiFS will actually call UBI
to write/read during a data fault, or is this deferred somehow?

Thanks,
Bill Pringlemeir.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/locking/rwsem-spinlock.c#n123
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/locking/rwsem-spinlock.c#n189



More information about the linux-mtd mailing list