From: Oleksandr Natalenko <oleksandr@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org, "Jonathan Corbet" <corbet@lwn.net>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Huang Ying" <ying.huang@intel.com>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
"Will Deacon" <will@kernel.org>,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
"Laurent Dufour" <ldufour@linux.ibm.com>,
"Stephen Kitt" <steve@sk2.org>, "Rob Herring" <robh@kernel.org>,
"Joel Savitz" <jsavitz@redhat.com>,
"Kees Cook" <keescook@chromium.org>,
"Xiaoming Ni" <nixiaoming@huawei.com>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Renaud Métrich" <rmetrich@redhat.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Grzegorz Halat" <ghalat@redhat.com>, "Qi Guo" <qguo@redhat.com>
Subject: Re: [PATCH] core_pattern: add CPU specifier
Date: Wed, 07 Sep 2022 08:15:06 +0200 [thread overview]
Message-ID: <5599808.DvuYhMxLoT@redhat.com> (raw)
In-Reply-To: <87r10ob0st.fsf@email.froward.int.ebiederm.org>
Hello.
On středa 7. září 2022 0:22:42 CEST Eric W. Biederman wrote:
> Oleksandr Natalenko <oleksandr@redhat.com> writes:
>
> > Statistically, in a large deployment regular segfaults may indicate a CPU issue.
> >
> > Currently, it is not possible to find out what CPU the segfault happened on.
> > There are at least two attempts to improve segfault logging with this regard,
> > but they do not help in case the logs rotate.
> >
> > Hence, lets make sure it is possible to permanently record a CPU
> > the task ran on using a new core_pattern specifier.
>
> I am puzzled why make it part of the file name, and not part of the
> core file? Say an elf note?
This might be a good idea too, and one approach doesn't exclude the other one.
> The big advantage is that you could always capture the cpu and
> will not need to take special care configuring your system to
> capture that information.
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.
Thanks.
> Eric
>
> > Suggested-by: Renaud Métrich <rmetrich@redhat.com>
> > Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
> > ---
> > Documentation/admin-guide/sysctl/kernel.rst | 1 +
> > fs/coredump.c | 5 +++++
> > include/linux/coredump.h | 1 +
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
> > index 835c8844bba48..b566fff04946b 100644
> > --- a/Documentation/admin-guide/sysctl/kernel.rst
> > +++ b/Documentation/admin-guide/sysctl/kernel.rst
> > @@ -169,6 +169,7 @@ core_pattern
> > %f executable filename
> > %E executable path
> > %c maximum size of core file by resource limit RLIMIT_CORE
> > + %C CPU the task ran on
> > %<OTHER> both are dropped
> > ======== ==========================================
> >
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index a8661874ac5b6..166d1f84a9b17 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> > @@ -325,6 +325,10 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm,
> > err = cn_printf(cn, "%lu",
> > rlimit(RLIMIT_CORE));
> > break;
> > + /* CPU the task ran on */
> > + case 'C':
> > + err = cn_printf(cn, "%d", cprm->cpu);
> > + break;
> > default:
> > break;
> > }
> > @@ -535,6 +539,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
> > */
> > .mm_flags = mm->flags,
> > .vma_meta = NULL,
> > + .cpu = raw_smp_processor_id(),
> > };
> >
> > audit_core_dumps(siginfo->si_signo);
> > diff --git a/include/linux/coredump.h b/include/linux/coredump.h
> > index 08a1d3e7e46d0..191dcf5af6cb9 100644
> > --- a/include/linux/coredump.h
> > +++ b/include/linux/coredump.h
> > @@ -22,6 +22,7 @@ struct coredump_params {
> > struct file *file;
> > unsigned long limit;
> > unsigned long mm_flags;
> > + int cpu;
> > loff_t written;
> > loff_t pos;
> > loff_t to_skip;
--
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
next prev parent reply other threads:[~2022-09-07 6:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-03 6:43 [PATCH] core_pattern: add CPU specifier Oleksandr Natalenko
2022-09-03 7:20 ` Oleg Nesterov
2022-09-04 18:27 ` Andrew Morton
2022-09-04 19:38 ` Oleg Nesterov
2022-09-06 22:22 ` Eric W. Biederman
2022-09-07 6:15 ` Oleksandr Natalenko [this message]
2022-09-07 17:34 ` Oleg Nesterov
2022-09-07 22:00 ` Eric W. Biederman
2022-09-08 6:11 ` Oleksandr Natalenko
2022-09-07 15:53 ` Luis Chamberlain
2022-09-08 6:45 ` Renaud Métrich
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=5599808.DvuYhMxLoT@redhat.com \
--to=oleksandr@redhat.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=ebiederm@xmission.com \
--cc=ghalat@redhat.com \
--cc=gpiccoli@igalia.com \
--cc=jsavitz@redhat.com \
--cc=keescook@chromium.org \
--cc=ldufour@linux.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=nixiaoming@huawei.com \
--cc=oleg@redhat.com \
--cc=qguo@redhat.com \
--cc=rmetrich@redhat.com \
--cc=robh@kernel.org \
--cc=steve@sk2.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.