linux-kernel - Re: [PATCH] core_pattern: add CPU specifier

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: <877d2ec0ac.fsf@email.froward.int.ebiederm.org>
Date:   Wed, 07 Sep 2022 17:00:43 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Oleksandr Natalenko <oleksandr@...hat.com>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Huang Ying <ying.huang@...el.com>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Will Deacon <will@...nel.org>,
        "Guilherme G . Piccoli" <gpiccoli@...lia.com>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        Stephen Kitt <steve@....org>, Rob Herring <robh@...nel.org>,
        Joel Savitz <jsavitz@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Xiaoming Ni <nixiaoming@...wei.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Renaud Métrich <rmetrich@...hat.com>,
        Grzegorz Halat <ghalat@...hat.com>, Qi Guo <qguo@...hat.com>
Subject: Re: [PATCH] core_pattern: add CPU specifier

Oleg Nesterov <oleg@...hat.com> writes:

> On 09/07, Oleksandr Natalenko wrote:
>>
>> The advantage of having CPU recorded in the file name is that
>> in case of multiple cores one can summarise them with a simple
>> ls+grep without invoking a fully-featured debugger to find out
>> whether the segfaults happened on the same CPU.
>
> Besides, if you only need to gather the statistics about the faulting
> CPU(s), you do not even need to actually dump the the core. For example,
> something like
>
> 	#!/usr/bin/sh
>
> 	echo $* >> path/to/coredump-stat.txt
>
> and
> 	echo '| path-to-script-above %C' >/proc/sys/kernel/core_pattern
>
> can help.

So I am confused.  I thought someone had modified print_fatal_signal
to print this information.  Looking at the code now I don't see it,
but perhaps that is in linux-next somewhere.

That would seem to be the really obvious place to put this and much
closer to the original fault so we ware more likely to record the
cpu on which things actually happened on.

If we don't care about the core dump just getting the information in
syslog where it can be analyzed seems like the thing to do.

For a developers box putting it in core pattern makes sense, isn't a
hinderance to use.  For anyone else's box the information needs to come
out in a way that allows automated tools to look for a pattern.
Requiring someone to take an extra step to print the information seems
a hinderance to automated tools doing the looking.

Eric