From: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
To: Michael Neuling <mikey@neuling.org>
Cc: linux-kernel@vger.kernel.org,
"Alastair D'Silva" <alastair@d-silva.org>,
Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
Balbir Singh <bsingharora@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Cyril Bur <cyrilbur@gmail.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Simon Guo <wei.guo.simon@gmail.com>,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
"Tobin C . Harding" <me@tobin.cc>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 0/7] powerpc: Modernize unhandled signals message
Date: Wed, 25 Jul 2018 16:36:47 -0300 [thread overview]
Message-ID: <20180725193647.GA23643@kermit-br-ibm-com> (raw)
In-Reply-To: <0f185351330a7f1d66409fe6a2dc02aae6826039.camel@neuling.org>
Hi, Mikey.
On Wed, Jul 25, 2018 at 05:00:21PM +1000, Michael Neuling wrote:
> On Tue, 2018-07-24 at 16:27 -0300, Murilo Opsfelder Araujo wrote:
> > Hi, everyone.
> >
> > This series was inspired by the need to modernize and display more
> > informative messages about unhandled signals.
> >
> > The "unhandled signal NN" is not very informative. We thought it would
> > be helpful adding a human-readable message describing what the signal
> > number means, printing the VMA address, and dumping the instructions.
> >
> > We can add more informative messages, like informing what each code of a
> > SIGSEGV signal means. We are open to suggestions.
> >
> > I have collected some early feedback from Michael Ellerman about this
> > series and would love to hear more feedback from you all.
>
> Nice.. the instruction dump would have been very handy when debugging the PCR
> init issue I had a month or so back.
>
> > Before this series:
> >
> > Jul 24 13:01:07 localhost kernel: pandafault[5989]: unhandled signal 11 at 00000000100007d0 nip 000000001000061c lr 00003fff85a75100 code 2
> >
> > After this series:
> >
> > Jul 24 13:08:01 localhost kernel: pandafault[10758]: segfault (11) at 00000000100007d0 nip 000000001000061c lr 00007fffabc85100 code 2 in pandafault[10000000+10000]
> > Jul 24 13:08:01 localhost kernel: Instruction dump:
> > Jul 24 13:08:01 localhost kernel: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821ffc1 7c3f0b78 3d22fffe
> > Jul 24 13:08:01 localhost kernel: 392988d0 f93f0020 e93f0020 39400048 <99490000> 39200000 7d234b78 383f0040
>
> What happens if we get a sudden flood of these from different processes that
> overlap their output? Are we going to be able to match up the process with
> instruction dump?
As to the flood of messages, ___ratelimit() makes me think that we'll
likely see some warn messages informing how many show_signal_msg()
callbacks were suppressed, instead of interleaved messages and
instruction dumps.
As to matching process with instruction dump, I believe we'd need more
information to glue them together.
What if we modify show_instructions() to accept a string prefix to be
printed along with each line?
> Should we prefix every line with the PID to avoid this?
That's possible. An alternative would be prefixing each line with the
process name and its PID, as in the first line. For example:
pandafault[10758]: segfault (11) at 00000000100007d0 nip 000000001000061c lr 00007fffabc85100 code 2 in pandafault[10000000+10000]
pandafault[10758]: Instruction dump:
pandafault[10758]: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821ffc1 7c3f0b78 3d22fffe
pandafault[10758]: 392988d0 f93f0020 e93f0020 39400048 <99490000> 39200000 7d234b78 383f0040
The above can be interleaved with other messages and we'll still be able
to match process and its corresponding instruction dump.
Cheers
Murilo
next prev parent reply other threads:[~2018-07-25 19:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-24 19:27 [PATCH 0/7] powerpc: Modernize unhandled signals message Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 1/7] powerpc/traps: Print unhandled signals in a separate function Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 2/7] powerpc/traps: Return early in show_signal_msg() Murilo Opsfelder Araujo
2018-07-25 15:42 ` LEROY Christophe
2018-07-25 20:31 ` Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 3/7] powerpc/reg: Add REG_FMT definition Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 4/7] powerpc/traps: Use REG_FMT in show_signal_msg() Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 5/7] powerpc/traps: Print VMA for unhandled signals Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 6/7] powerpc/traps: Print signal name " Murilo Opsfelder Araujo
2018-07-25 15:19 ` Gustavo Romero
2018-07-25 19:41 ` Murilo Opsfelder Araujo
2018-07-25 15:49 ` LEROY Christophe
2018-07-25 20:06 ` Murilo Opsfelder Araujo
2018-07-24 19:27 ` [PATCH 7/7] powerpc/traps: Show instructions on exceptions Murilo Opsfelder Araujo
2018-07-25 16:01 ` LEROY Christophe
2018-07-25 20:51 ` Murilo Opsfelder Araujo
2018-07-25 7:00 ` [PATCH 0/7] powerpc: Modernize unhandled signals message Michael Neuling
2018-07-25 19:36 ` Murilo Opsfelder Araujo [this message]
2018-07-26 2:11 ` Michael Neuling
2018-07-26 2:20 ` Michael Ellerman
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=20180725193647.GA23643@kermit-br-ibm-com \
--to=muriloo@linux.ibm.com \
--cc=alastair@d-silva.org \
--cc=andrew.donnellan@au1.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bsingharora@gmail.com \
--cc=christophe.leroy@c-s.fr \
--cc=cyrilbur@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=me@tobin.cc \
--cc=mikey@neuling.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=sukadev@linux.vnet.ibm.com \
--cc=wei.guo.simon@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).