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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <0364bdc4-ddf9-85de-1128-8fc8791d63dd@linux.vnet.ibm.com>
Date:   Wed, 25 Jul 2018 12:19:00 -0300
From:   Gustavo Romero <gromero@...ux.vnet.ibm.com>
To:     Murilo Opsfelder Araujo <muriloo@...ux.ibm.com>,
        linux-kernel@...r.kernel.org
Cc:     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 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.

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


Cheers,
Gustavo