linux-kernel - Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled signals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 25 Jul 2018 16:41:05 -0300
From:   Murilo Opsfelder Araujo <muriloo@...ux.ibm.com>
To:     Gustavo Romero <gromero@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, Michael Neuling <mikey@...ling.org>,
        Simon Guo <wei.guo.simon@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Paul Mackerras <paulus@...ba.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Andrew Donnellan <andrew.donnellan@....ibm.com>,
        "Alastair D'Silva" <alastair@...ilva.org>,
        Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org, Cyril Bur <cyrilbur@...il.com>,
        "Tobin C . Harding" <me@...in.cc>
Subject: Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled
 signals

Hi, Gustavo.

On Wed, Jul 25, 2018 at 12:19:00PM -0300, Gustavo Romero wrote:
> Hi Murilo,
> 
> LGTM.
> 
> Just a comment:
> 
> On 07/24/2018 04:27 PM, Murilo Opsfelder Araujo wrote:
> > This adds a human-readable name in the unhandled signal message.
> > 
> > Before this patch, a page fault looked like:
> > 
> >      Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal 11 at 00000000100007d0 nip 000000001000061c lr 00007fff93c55100 code 2 in pandafault[10000000+10000]
> > 
> > After this patch, a page fault looks like:
> > 
> >      Jul 11 18:14:48 localhost kernel: pandafault[6352]: segfault (11) at 000000013a2a09f8 nip 000000013a2a086c lr 00007fffb63e5100 code 2 in pandafault[13a2a0000+10000]
> 
> I _really_ don't want to bikeshed here, but I vouch for keeping the
> "unhandled" word before the signal name, like:
> 
> [...] pandafault[6352]: unhandled segfault (11) at 000000013a2a09f8 nip [...]
> 
> because the issue reported here is really that we got a segfault _and_
> there was no handler to catch it.

Either way works for me.

> But feel free to wait for additional comments to decide it.

Sure.  I intend to wait a couple of weeks to respin the series based on
community feedback.

Cheers
Murilo