From: Oleg Nesterov <oleg@redhat.com>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] If init dies, log a signal which killed it, if any.
Date: Fri, 20 Jan 2012 18:00:10 +0100 [thread overview]
Message-ID: <20120120170010.GA14970@redhat.com> (raw)
In-Reply-To: <1327077547-3925-1-git-send-email-vda.linux@googlemail.com>
On 01/20, Denys Vlasenko wrote:
>
> I just received another user's pleas for help when their
> init mystriously dies. I again explained that they need to check
> whether it dies because of bad instruction, a segv, or something else.
>
> Which prompted me to make kernel do this first step automatically.
> We can easily detect when the death is from e.g. SIGILL,
> and let user know that.
>
> The code is fairly self-explanatory. Compile-tested.
>
> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
> ---
> kernel/exit.c | 23 ++++++++++++++++++++++-
> 1 files changed, 22 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 294b170..89d0892 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -710,8 +710,29 @@ static struct task_struct *find_new_reaper(struct task_struct *father)
>
> if (unlikely(pid_ns->child_reaper == father)) {
> write_unlock_irq(&tasklist_lock);
> - if (unlikely(pid_ns == &init_pid_ns))
> + if (unlikely(pid_ns == &init_pid_ns)) {
> + /*
> + * The situation when init segfaults is rather typical.
> + * Give some useful diagnostics: do we die on signal?
> + */
> + if (fatal_signal_pending(father)) {
The fatal signal can be already dequeued. Although mostly this works.
> + const char *msg = "";
> + sigset_t *mask = &father->pending.signal;
> + /* Only force_sig()ned signals kill init */
> + if (sigismember(mask, SIGSEGV))
> + msg = " SIGSEGV";
> + if (sigismember(mask, SIGBUS))
> + msg = " SIGBUS";
> + if (sigismember(mask, SIGILL))
> + msg = " SIGILL";
> + if (sigismember(mask, SIGFPE))
> + msg = " SIGFPE";
This doesn't look right too. Again, if it was killed by SIGSEGV
this signal can be dequeued and not pending.
> + /* (do we want to check SIGTRAP too?) */
> + printk(KERN_ERR
> + "init received fatal signal%s\n", msg);
> + }
I'd suggest this trivial change instead,
- panic("Attempted to kill init!");
+ panic("Attempted to kill init! code=%08x\n",
+ father->signal->group_exit_code ?: father->exit_code);
Oleg.
prev parent reply other threads:[~2012-01-20 17:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 16:39 [PATCH] If init dies, log a signal which killed it, if any Denys Vlasenko
2012-01-20 17:00 ` Oleg Nesterov [this message]
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=20120120170010.GA14970@redhat.com \
--to=oleg@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vda.linux@googlemail.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.