From: Artem Bityutskiy <dedekind1@gmail.com>
To: Daniel Mack <daniel@caiaq.de>
Cc: Sven Neumann <s.neumann@raumfeld.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Adrian Hunter <adrian.hunter@nokia.com>
Subject: Re: UBIFS: Oops while rebooting 2.6.34-rc6
Date: Fri, 07 May 2010 18:23:46 +0300 [thread overview]
Message-ID: <1273245826.4537.294.camel@localhost> (raw)
In-Reply-To: <20100507131652.GT30801@buzzloop.caiaq.de>
On Fri, 2010-05-07 at 15:16 +0200, Daniel Mack wrote:
> Hi,
>
> We've had a kernel Oops today when rebooting an ARM PXA based machine
> while file I/O via SSH was outstanding.
>
> Daniel
>
> # reboot
> # [ 671.190085] UBIFS: un-mount UBI device 0, volume 1
> The system is going down NOW!
> Sent SIGTERM to all processes
> [ 672.083833] Unable to handle kernel NULL pointer dereference at virtual address 000000ac
> [ 672.094587] pgd = c0004000
> [ 672.097301] [000000ac] *pgd=00000000
> [ 672.100850] Internal error: Oops: 817 [#1]
> [ 672.104919] last sysfs file: /sys/devices/platform/spi_gpio.0/spi0.2/value
It's Firday, and I want to go home, so here is another quick idea for
you where to dig.
When the system reboots it re-mounts the FS to RO mode, usually. And
there is some emergency remount business (see do_emergency_remount()),
which will re-mount the FS even if there are files opened for writing.
So, if there is a UBIFS or VFS bug, and somehow one process is in
make_reservation() and is about to write something, and another process
managed to re-mount the FS to R/O mode, then we may ooops, because UBIFS
frees these 'wbuf' objects when it is mounted to R/O (see
ubifs_remount_ro()).
So, inject printks to ubifs_remount_ro() to check this theory.
Have a nice weekend and bughunting!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Daniel Mack <daniel@caiaq.de>
Cc: Adrian Hunter <adrian.hunter@nokia.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Sven Neumann <s.neumann@raumfeld.com>
Subject: Re: UBIFS: Oops while rebooting 2.6.34-rc6
Date: Fri, 07 May 2010 18:23:46 +0300 [thread overview]
Message-ID: <1273245826.4537.294.camel@localhost> (raw)
In-Reply-To: <20100507131652.GT30801@buzzloop.caiaq.de>
On Fri, 2010-05-07 at 15:16 +0200, Daniel Mack wrote:
> Hi,
>
> We've had a kernel Oops today when rebooting an ARM PXA based machine
> while file I/O via SSH was outstanding.
>
> Daniel
>
> # reboot
> # [ 671.190085] UBIFS: un-mount UBI device 0, volume 1
> The system is going down NOW!
> Sent SIGTERM to all processes
> [ 672.083833] Unable to handle kernel NULL pointer dereference at virtual address 000000ac
> [ 672.094587] pgd = c0004000
> [ 672.097301] [000000ac] *pgd=00000000
> [ 672.100850] Internal error: Oops: 817 [#1]
> [ 672.104919] last sysfs file: /sys/devices/platform/spi_gpio.0/spi0.2/value
It's Firday, and I want to go home, so here is another quick idea for
you where to dig.
When the system reboots it re-mounts the FS to RO mode, usually. And
there is some emergency remount business (see do_emergency_remount()),
which will re-mount the FS even if there are files opened for writing.
So, if there is a UBIFS or VFS bug, and somehow one process is in
make_reservation() and is about to write something, and another process
managed to re-mount the FS to R/O mode, then we may ooops, because UBIFS
frees these 'wbuf' objects when it is mounted to R/O (see
ubifs_remount_ro()).
So, inject printks to ubifs_remount_ro() to check this theory.
Have a nice weekend and bughunting!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-05-07 15:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 13:16 UBIFS: Oops while rebooting 2.6.34-rc6 Daniel Mack
2010-05-07 13:16 ` Daniel Mack
2010-05-07 15:12 ` Artem Bityutskiy
2010-05-07 15:12 ` Artem Bityutskiy
2010-05-07 15:23 ` Artem Bityutskiy [this message]
2010-05-07 15:23 ` Artem Bityutskiy
2010-05-07 15:26 ` Daniel Mack
2010-05-07 15:26 ` Daniel Mack
2010-06-05 11:50 ` Artem Bityutskiy
2010-06-05 11:50 ` Artem Bityutskiy
2010-05-10 7:46 ` Adrian Hunter
2010-05-10 7:46 ` Adrian Hunter
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=1273245826.4537.294.camel@localhost \
--to=dedekind1@gmail.com \
--cc=adrian.hunter@nokia.com \
--cc=daniel@caiaq.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=s.neumann@raumfeld.com \
/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.