From: chunlei.wang <Chunlei.wang@mediatek.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: weiwei.zhang@mediatek.com, wsd_upstream@mediatek.com,
Peter Zijlstra <peterz@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH] siganl: ignore other signals when doing coredump
Date: Fri, 31 Jul 2020 16:54:14 +0800 [thread overview]
Message-ID: <1596185654.11648.1.camel@mbjsdccf07> (raw)
In-Reply-To: <20200723175126.cf6a660e46c8da26b1293eb4@linux-foundation.org>
Please tell us much more about why you think Linux would benefit from
this change. Precisely what operational problems are you seeing with
the current code?
=>
Sorry for the late reply.
If coredump is incomplete, R&D can not find root cause through
coredump.
If the issue is seldom, this modification will speed up the process of
solving the problem.
When one thread occur crash, if the default action of the signal
is dump, it will enter do_coredump flow and SIGNAL_GROUP_COREDUMP is
set to signal->flags. If SIGKILL is received, the function of
prepare_signal will check signal->flags, if the bit of
SIGNAL_GROUP_COREDUMP is true and SIGNAL_GROUP_EXIT is false, the
SIGKILL will respond immediately, process will do exit flow, but now
process is doing coredump. This is abnormal, do_coredump will be break ,
causing causing the coredump to be truncated.
On Thu, 2020-07-23 at 17:51 -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 14:52:23 +0800 "chunlei.wang" <Chunlei.wang@mediatek.com> wrote:
>
> > do_coredump flow is interrupted by SIGKILL,
> > causing the coredump to be truncated.
> >
>
> Please tell us much more about why you think Linux would benefit from
> this change. Precisely what operational problems are you seeing with
> the current code?
>
>
> > ---
> > arch/Kconfig | 12 ++++++++++++
> > kernel/signal.c | 8 ++++++++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 8cc35dc556c7..559eac47093e 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -834,6 +834,18 @@ config OLD_SIGACTION
> > config COMPAT_OLD_SIGACTION
> > bool
> >
> > +config IGNORE_ANY_SIGNALS
> > + tristate "ignore any signals when coredump is doing"
> > + default n
> > + help
> > + The sigkill is very special. If a process receives a sigkill, it
> > will
> > + immediately respond to the sigkill. When a process is abnormal and
> > + collecting coredump, the do_coredump flow will be interrupted by
> > + SIGKILL, causing the coredump to be truncated. This truncated
> > coredump
> > + is incomplete, and also gdb can't load.
> > + Maybe we can ignore any signlas when process is collecting coredump.
> > + This config can decide whether to ignore any signals.
> > +
> > config COMPAT_32BIT_TIME
> > bool "Provide system calls for 32-bit time_t"
> > default !64BIT || COMPAT
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 5ca48cc5da76..ccae3c84eb6d 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -903,6 +903,14 @@ static bool prepare_signal(int sig, struct
> > task_struct *p, bool force)
> > sigset_t flush;
> >
> > if (signal->flags & (SIGNAL_GROUP_EXIT | SIGNAL_GROUP_COREDUMP)) {
> > +
> > +#if defined CONFIG_IGNORE_ANY_SIGNALS
> > + if (signal->flags & SIGNAL_GROUP_COREDUMP) {
> > + pr_debug("[%d:%s] skip sig %d due to coredump is doing\n",
> > + p->pid, p->comm, sig);
> > + return false;
> > + }
> > +#endif
> > if (!(signal->flags & SIGNAL_GROUP_EXIT))
> > return sig == SIGKILL;
> > /*
> > --
> > 2.18.0
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2020-07-31 9:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 6:52 [PATCH] siganl: ignore other signals when doing coredump chunlei.wang
2020-07-24 0:51 ` Andrew Morton
2020-07-31 8:54 ` chunlei.wang [this message]
2020-08-03 19:17 ` Oleg Nesterov
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=1596185654.11648.1.camel@mbjsdccf07 \
--to=chunlei.wang@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=weiwei.zhang@mediatek.com \
--cc=will@kernel.org \
--cc=wsd_upstream@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox