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]
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

Powered by blists - more mailing lists