From: Don Zickus <dzickus@redhat.com>
To: tony.luck@intel.com
Cc: mjg@redhat.com, linux-kernel@vger.kernel.org
Subject: pstore dump inside an nmi handler
Date: Fri, 8 Jul 2011 16:17:31 -0400 [thread overview]
Message-ID: <20110708201731.GA3025@redhat.com> (raw)
Hi Tony,
I was playing with the APEI EINJ module, injecting errors trying to
capture a GHES record, then panic into a kdump kernel and reboot.
Matthew brought to my attention that pstore should capture an error record
on the panic path using kmsg_dump(). After injecting an error with EINJ,
I went to check to see if there was a pstore entry. There wasn't.
Playing on another box, I noticed the machine double faulted and didn't
even make it into a kdump kernel.
Upon investigation, I noticed that when a fatal error occurs on the
platform, it will generate an NMI that will be handle by the
ghes_nmi_handler. This handler calls panic() which calls kmsg_dump()
which calls pstore_dump().
Inside pstore_dump(), the first thing it tries to grab is a mutex_lock()
(inside an nmi hander). This seems to be the root cause of my problems.
I am not familiar enough with pstore to just modify its locking, so I
wanted to ask you.
My first thought was to wrap the mutex_lock with a 'if !in_nmi()', but that
seemed kinda hacky. Then I was wondering if there was a way to do this
locklessly or atomically because you are only dealing with whole blocks I
think. I don't know.
Wanted to give you a heads up and seek your thoughts. I am willing to
hack up some code and test. :-)
Cheers,
Don
next reply other threads:[~2011-07-08 20:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 20:17 Don Zickus [this message]
2011-07-08 21:40 ` pstore dump inside an nmi handler Luck, Tony
2011-07-08 21:48 ` David Miller
2011-07-08 21:49 ` Matthew Garrett
2011-07-08 22:10 ` Luck, Tony
2011-07-11 15:39 ` Don Zickus
2011-07-13 18:15 ` Luck, Tony
2011-07-14 13:49 ` Don Zickus
2011-07-11 21:55 ` Don Zickus
2011-07-12 15:34 ` Don Zickus
2011-07-13 16:58 ` Luck, Tony
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=20110708201731.GA3025@redhat.com \
--to=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=tony.luck@intel.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.