From: Daniel Mack <daniel@caiaq.de>
To: Artem Bityutskiy <dedekind1@gmail.com>
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, 7 May 2010 17:26:40 +0200 [thread overview]
Message-ID: <20100507152640.GX30801@buzzloop.caiaq.de> (raw)
In-Reply-To: <1273245826.4537.294.camel@localhost>
On Fri, May 07, 2010 at 06:23:46PM +0300, Artem Bityutskiy wrote:
> 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!
Thanks for your feedback - I'll give that a try next week.
Have a good weekend :)
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Mack <daniel@caiaq.de>
To: Artem Bityutskiy <dedekind1@gmail.com>
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, 7 May 2010 17:26:40 +0200 [thread overview]
Message-ID: <20100507152640.GX30801@buzzloop.caiaq.de> (raw)
In-Reply-To: <1273245826.4537.294.camel@localhost>
On Fri, May 07, 2010 at 06:23:46PM +0300, Artem Bityutskiy wrote:
> 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!
Thanks for your feedback - I'll give that a try next week.
Have a good weekend :)
Daniel
next prev parent reply other threads:[~2010-05-07 15:27 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
2010-05-07 15:23 ` Artem Bityutskiy
2010-05-07 15:26 ` Daniel Mack [this message]
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=20100507152640.GX30801@buzzloop.caiaq.de \
--to=daniel@caiaq.de \
--cc=adrian.hunter@nokia.com \
--cc=dedekind1@gmail.com \
--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.