From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: Richard Weinberger <richard@nod.at>
Cc: "Wiedemer, Thorsten \(Lawo AG\)" <Thorsten.Wiedemer@lawo.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBI leb_write_unlock NULL pointer Oops (continuation)
Date: Fri, 14 Feb 2014 12:11:30 -0500 [thread overview]
Message-ID: <87d2ipwrel.fsf@nbsps.com> (raw)
In-Reply-To: <52FBDE01.9030207@nod.at> (Richard Weinberger's message of "Wed, 12 Feb 2014 21:48:01 +0100")
> 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@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
next prev parent reply other threads:[~2014-02-14 17:19 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 8:51 UBI leb_write_unlock NULL pointer Oops (continuation) Wiedemer, Thorsten (Lawo AG)
2014-02-03 9:38 ` Richard Weinberger
2014-02-03 10:31 ` AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-03 11:02 ` Richard Weinberger
2014-02-03 12:51 ` AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-03 13:56 ` Richard Weinberger
2014-02-04 7:22 ` Artem Bityutskiy
2014-02-04 7:46 ` Richard Weinberger
2014-02-04 7:54 ` Artem Bityutskiy
2014-02-04 15:45 ` UBI leb_write_unlock NULL pointer Oops (continuation) on ARM926 Bill Pringlemeir
2014-02-04 15:45 ` Bill Pringlemeir
2014-02-04 17:05 ` Bill Pringlemeir
2014-02-04 17:05 ` Bill Pringlemeir
2014-02-04 19:57 ` Bill Pringlemeir
2014-02-04 19:57 ` Bill Pringlemeir
2014-02-04 20:07 ` Richard Weinberger
2014-02-04 20:07 ` Richard Weinberger
2014-02-04 17:01 ` AW: UBI leb_write_unlock NULL pointer Oops (continuation) Wiedemer, Thorsten (Lawo AG)
2014-02-04 17:52 ` Wiedemer, Thorsten (Lawo AG)
2014-02-05 8:29 ` Richard Weinberger
2014-02-05 21:45 ` Bill Pringlemeir
2014-02-05 22:13 ` Richard Weinberger
2014-02-05 22:23 ` Bill Pringlemeir
2014-02-06 13:05 ` AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-06 16:00 ` Bill Pringlemeir
2014-02-11 8:01 ` Wiedemer, Thorsten (Lawo AG)
2014-02-11 15:25 ` Bill Pringlemeir
2014-02-12 15:18 ` AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-12 17:46 ` Richard Weinberger
2014-02-12 18:11 ` AW: AW: " Bill Pringlemeir
2014-02-12 18:21 ` Bill Pringlemeir
2014-02-12 20:48 ` Richard Weinberger
2014-02-14 17:11 ` Bill Pringlemeir [this message]
2014-02-18 8:25 ` Ziegler, Emanuel (Lawo AG)
2014-02-19 11:09 ` Ziegler, Emanuel (Lawo AG)
2014-02-20 15:21 ` AW: AW: AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-20 17:26 ` Bill Pringlemeir
2014-02-20 17:38 ` Bill Pringlemeir
2014-02-21 8:55 ` AW: AW: AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-21 9:28 ` Quiniou, Benoit (Lawo AG)
2014-02-21 17:53 ` AW: " Bill Pringlemeir
2014-02-21 18:12 ` Richard Weinberger
2014-02-21 19:45 ` Bill Pringlemeir
2014-02-22 0:49 ` Bill Pringlemeir
2014-02-22 8:32 ` Richard Weinberger
2014-02-24 15:09 ` Bill Pringlemeir
2014-02-24 15:36 ` Richard Weinberger
2014-02-24 15:45 ` Bill Pringlemeir
2014-02-24 15:48 ` Bill Pringlemeir
2014-03-05 20:57 ` Richard Weinberger
2014-03-05 21:30 ` Bill Pringlemeir
2014-03-05 21:42 ` Bill Pringlemeir
2014-03-05 23:11 ` Richard Weinberger
2014-03-05 23:12 ` Richard Weinberger
2014-02-04 19:49 ` Andrew Ruder
2014-02-05 8:39 ` AW: " Wiedemer, Thorsten (Lawo AG)
2014-02-05 20:13 ` Andrew Ruder
2015-10-16 12:17 ` Wojciech Nizinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2ipwrel.fsf@nbsps.com \
--to=bpringlemeir@nbsps.com \
--cc=Thorsten.Wiedemer@lawo.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.