From: Oleg Nesterov <oleg@redhat.com>
To: Enke Chen <enkechen@cisco.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Khalid Aziz <khalid.aziz@oracle.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Helge Deller <deller@gmx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Christian Brauner <christian@brauner.io>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Rik
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 15 Oct 2018 14:05:21 +0200 [thread overview]
Message-ID: <20181015120521.GA10146@redhat.com> (raw)
In-Reply-To: <e7ed306f-8992-9d00-bcab-5131159e8d89@cisco.com>
On 10/12, Enke Chen wrote:
>
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to specify the
> signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new
> signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD.
To be honest, I can't say I like this new feature...
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -696,6 +696,10 @@ struct task_struct {
> int exit_signal;
> /* The signal sent when the parent dies: */
> int pdeath_signal;
> +
> + /* The signal sent prior to a child's coredump: */
> + int predump_signal;
> +
At least, I think predump_signal should live in signal_struct, not
task_struct.
(pdeath_signal too, but it is too late to change (fix) this awkward API).
> +static void do_notify_parent_predump(struct task_struct *tsk)
> +{
> + struct sighand_struct *sighand;
> + struct task_struct *parent;
> + struct kernel_siginfo info;
> + unsigned long flags;
> + int sig;
> +
> + parent = tsk->real_parent;
So, debuggere won't be notified, only real_parent...
> + sig = parent->predump_signal;
probably ->predump_signal should be cleared on exec?
> + /* Check again with tasklist_lock" locked by the caller */
> + if (!valid_predump_signal(sig))
> + return;
I don't understand why we need valid_predump_signal() at all.
> bool get_signal(struct ksignal *ksig)
> {
> struct sighand_struct *sighand = current->sighand;
> @@ -2497,6 +2535,19 @@ bool get_signal(struct ksignal *ksig)
> current->flags |= PF_SIGNALED;
>
> if (sig_kernel_coredump(signr)) {
> + /*
> + * Notify the parent prior to the coredump if the
> + * parent is interested in such a notificaiton.
> + */
> + int p_sig = current->real_parent->predump_signal;
> +
> + if (valid_predump_signal(p_sig)) {
> + read_lock(&tasklist_lock);
> + do_notify_parent_predump(current);
> + read_unlock(&tasklist_lock);
> + cond_resched();
perhaps this should be called by do_coredump() after coredump_wait() kills
all the sub-threads?
> +static int prctl_set_predump_signal(struct task_struct *tsk, pid_t pid, int sig)
> +{
> + struct task_struct *p;
> + int error;
> +
> + /* 0 is valid for disabling the feature */
> + if (sig && !valid_predump_signal(sig))
> + return -EINVAL;
> +
> + /* For the current task, the common case */
> + if (pid == 0) {
> + tsk->predump_signal = sig;
> + return 0;
> + }
> +
> + error = -ESRCH;
> + rcu_read_lock();
> + p = find_task_by_vpid(pid);
> + if (p) {
> + if (!set_predump_signal_perm(p))
> + error = -EPERM;
> + else {
> + error = 0;
> + p->predump_signal = sig;
> + }
> + }
> + rcu_read_unlock();
> + return error;
> +}
Why? I mean, why do we really want to support the pid != 0 case?
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Enke Chen <enkechen@cisco.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Khalid Aziz <khalid.aziz@oracle.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Helge Deller <deller@gmx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Christian Brauner <christian@brauner.io>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Roman Gushchin <guro@fb.com>,
Marcos Paulo de Souza <marcos.souza.org@gmail.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Yang Shi <yang.shi@linux.alibaba.com>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
"Victor Kamensky (kamensky)" <kamensky@cisco.com>,
xe-linux-external@cisco.com, Stefan Strogin <sstrogin@cisco.com>,
Eugene Syromiatnikov <esyr@redhat.com>
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 15 Oct 2018 14:05:21 +0200 [thread overview]
Message-ID: <20181015120521.GA10146@redhat.com> (raw)
Message-ID: <20181015120521.a9_Kjoa-cDAyWaXUmaXIA854ylrzcWG9nrT2VXU9t7I@z> (raw)
In-Reply-To: <e7ed306f-8992-9d00-bcab-5131159e8d89@cisco.com>
On 10/12, Enke Chen wrote:
>
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to specify the
> signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new
> signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD.
To be honest, I can't say I like this new feature...
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -696,6 +696,10 @@ struct task_struct {
> int exit_signal;
> /* The signal sent when the parent dies: */
> int pdeath_signal;
> +
> + /* The signal sent prior to a child's coredump: */
> + int predump_signal;
> +
At least, I think predump_signal should live in signal_struct, not
task_struct.
(pdeath_signal too, but it is too late to change (fix) this awkward API).
> +static void do_notify_parent_predump(struct task_struct *tsk)
> +{
> + struct sighand_struct *sighand;
> + struct task_struct *parent;
> + struct kernel_siginfo info;
> + unsigned long flags;
> + int sig;
> +
> + parent = tsk->real_parent;
So, debuggere won't be notified, only real_parent...
> + sig = parent->predump_signal;
probably ->predump_signal should be cleared on exec?
> + /* Check again with tasklist_lock" locked by the caller */
> + if (!valid_predump_signal(sig))
> + return;
I don't understand why we need valid_predump_signal() at all.
> bool get_signal(struct ksignal *ksig)
> {
> struct sighand_struct *sighand = current->sighand;
> @@ -2497,6 +2535,19 @@ bool get_signal(struct ksignal *ksig)
> current->flags |= PF_SIGNALED;
>
> if (sig_kernel_coredump(signr)) {
> + /*
> + * Notify the parent prior to the coredump if the
> + * parent is interested in such a notificaiton.
> + */
> + int p_sig = current->real_parent->predump_signal;
> +
> + if (valid_predump_signal(p_sig)) {
> + read_lock(&tasklist_lock);
> + do_notify_parent_predump(current);
> + read_unlock(&tasklist_lock);
> + cond_resched();
perhaps this should be called by do_coredump() after coredump_wait() kills
all the sub-threads?
> +static int prctl_set_predump_signal(struct task_struct *tsk, pid_t pid, int sig)
> +{
> + struct task_struct *p;
> + int error;
> +
> + /* 0 is valid for disabling the feature */
> + if (sig && !valid_predump_signal(sig))
> + return -EINVAL;
> +
> + /* For the current task, the common case */
> + if (pid == 0) {
> + tsk->predump_signal = sig;
> + return 0;
> + }
> +
> + error = -ESRCH;
> + rcu_read_lock();
> + p = find_task_by_vpid(pid);
> + if (p) {
> + if (!set_predump_signal_perm(p))
> + error = -EPERM;
> + else {
> + error = 0;
> + p->predump_signal = sig;
> + }
> + }
> + rcu_read_unlock();
> + return error;
> +}
Why? I mean, why do we really want to support the pid != 0 case?
Oleg.
next prev parent reply other threads:[~2018-10-15 12:05 UTC|newest]
Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 0:33 [PATCH] kernel/signal: Signal-based pre-coredump notification Enke Chen
2018-10-13 0:33 ` Enke Chen
2018-10-13 6:40 ` Greg Kroah-Hartman
2018-10-13 6:40 ` Greg Kroah-Hartman
2018-10-15 18:16 ` Enke Chen
2018-10-15 18:16 ` Enke Chen
2018-10-15 18:43 ` Greg Kroah-Hartman
2018-10-15 18:43 ` Greg Kroah-Hartman
2018-10-15 18:49 ` Enke Chen
2018-10-15 18:49 ` Enke Chen
2018-10-15 18:58 ` Greg Kroah-Hartman
2018-10-15 18:58 ` Greg Kroah-Hartman
2018-10-13 10:44 ` Christian Brauner
2018-10-13 10:44 ` Christian Brauner
2018-10-15 18:39 ` Enke Chen
2018-10-15 18:39 ` Enke Chen
2018-10-15 18:39 ` Enke Chen
2018-10-13 18:27 ` Jann Horn
2018-10-13 18:27 ` Jann Horn
2018-10-15 18:36 ` Enke Chen
2018-10-15 18:36 ` Enke Chen
2018-10-15 18:54 ` Jann Horn
2018-10-15 18:54 ` Jann Horn
2018-10-15 19:23 ` Enke Chen
2018-10-15 19:23 ` Enke Chen
2018-10-19 23:01 ` Enke Chen
2018-10-19 23:01 ` Enke Chen
2018-10-22 15:40 ` Jann Horn
2018-10-22 15:40 ` Jann Horn
2018-10-22 20:48 ` Enke Chen
2018-10-22 20:48 ` Enke Chen
2018-10-15 12:05 ` Oleg Nesterov [this message]
2018-10-15 12:05 ` Oleg Nesterov
2018-10-15 18:54 ` Enke Chen
2018-10-15 18:54 ` Enke Chen
2018-10-15 19:17 ` Enke Chen
2018-10-15 19:17 ` Enke Chen
2018-10-15 19:26 ` Enke Chen
2018-10-15 19:26 ` Enke Chen
2018-10-16 14:14 ` Oleg Nesterov
2018-10-16 14:14 ` Oleg Nesterov
2018-10-16 15:09 ` Eric W. Biederman
2018-10-16 15:09 ` Eric W. Biederman
2018-10-16 15:09 ` Eric W. Biederman
2018-10-17 0:39 ` Enke Chen
2018-10-17 0:39 ` Enke Chen
2018-10-15 21:21 ` Alan Cox
2018-10-15 21:21 ` Alan Cox
2018-10-15 21:31 ` Enke Chen
2018-10-15 21:31 ` Enke Chen
2018-10-15 23:28 ` Eric W. Biederman
2018-10-15 23:28 ` Eric W. Biederman
2018-10-15 23:28 ` Eric W. Biederman
2018-10-16 0:33 ` valdis.kletnieks
2018-10-16 0:33 ` valdis.kletnieks
2018-10-16 0:33 ` valdis.kletnieks
2018-10-16 0:54 ` Enke Chen
2018-10-16 0:54 ` Enke Chen
2018-10-16 15:26 ` Eric W. Biederman
2018-10-16 15:26 ` Eric W. Biederman
2018-10-16 15:26 ` Eric W. Biederman
2018-10-22 21:09 ` [PATCH v2] " Enke Chen
2018-10-22 21:09 ` Enke Chen
2018-10-23 9:23 ` Oleg Nesterov
2018-10-23 9:23 ` Oleg Nesterov
2018-10-23 19:43 ` Enke Chen
2018-10-23 19:43 ` Enke Chen
2018-10-23 21:40 ` Enke Chen
2018-10-23 21:40 ` Enke Chen
2018-10-24 13:52 ` Oleg Nesterov
2018-10-24 13:52 ` Oleg Nesterov
2018-10-24 21:56 ` Enke Chen
2018-10-24 21:56 ` Enke Chen
2018-10-24 5:39 ` [PATCH v3] " Enke Chen
2018-10-24 5:39 ` Enke Chen
2018-10-24 14:02 ` Oleg Nesterov
2018-10-24 14:02 ` Oleg Nesterov
2018-10-24 22:02 ` Enke Chen
2018-10-24 22:02 ` Enke Chen
2018-10-25 22:56 ` [PATCH v4] " Enke Chen
2018-10-25 22:56 ` Enke Chen
2018-10-26 8:28 ` Oleg Nesterov
2018-10-26 8:28 ` Oleg Nesterov
2018-10-26 22:23 ` Enke Chen
2018-10-26 22:23 ` Enke Chen
2018-10-29 11:18 ` Oleg Nesterov
2018-10-29 11:18 ` Oleg Nesterov
2018-10-29 21:08 ` Enke Chen
2018-10-29 21:08 ` Enke Chen
2018-10-29 22:31 ` [PATCH v5] " Enke Chen
2018-10-29 22:31 ` Enke Chen
2018-10-30 16:46 ` Oleg Nesterov
2018-10-30 16:46 ` Oleg Nesterov
2018-10-31 0:25 ` Enke Chen
2018-10-31 0:25 ` Enke Chen
2018-11-22 0:37 ` Andrew Morton
2018-11-22 0:37 ` Andrew Morton
2018-11-22 1:09 ` Enke Chen
2018-11-22 1:09 ` Enke Chen
2018-11-22 1:18 ` Enke Chen
2018-11-22 1:18 ` Enke Chen
2018-11-22 1:33 ` Andrew Morton
2018-11-22 1:33 ` Andrew Morton
2018-11-22 4:57 ` Enke Chen
2018-11-22 4:57 ` Enke Chen
2018-11-12 23:22 ` Enke Chen
2018-11-12 23:22 ` Enke Chen
2018-11-27 22:54 ` [PATCH v5 1/2] " Enke Chen
2018-11-27 22:54 ` Enke Chen
2018-11-28 15:19 ` Dave Martin
2018-11-28 15:19 ` Dave Martin
2018-11-29 0:15 ` Enke Chen
2018-11-29 0:15 ` Enke Chen
2018-11-29 11:55 ` Dave Martin
2018-11-29 11:55 ` Dave Martin
2018-11-30 0:27 ` Enke Chen
2018-11-30 0:27 ` Enke Chen
2018-11-30 12:03 ` Oleg Nesterov
2018-11-30 12:03 ` Oleg Nesterov
2018-12-05 6:47 ` Jann Horn
2018-12-05 6:47 ` Jann Horn
2018-12-04 22:37 ` Andrew Morton
2018-12-04 22:37 ` Andrew Morton
2018-12-06 17:29 ` Oleg Nesterov
2018-12-06 17:29 ` Oleg Nesterov
2018-10-25 22:56 ` [PATCH] selftests/prctl: selftest for pre-coredump signal notification Enke Chen
2018-10-25 22:56 ` Enke Chen
2018-11-27 22:54 ` [PATCH v5 2/2] " Enke Chen
2018-11-27 22:54 ` Enke Chen
2018-10-24 13:29 ` [PATCH v2] kernel/signal: Signal-based pre-coredump notification Eric W. Biederman
2018-10-24 13:29 ` Eric W. Biederman
2018-10-24 13:29 ` Eric W. Biederman
2018-10-24 23:50 ` Enke Chen
2018-10-24 23:50 ` Enke Chen
2018-10-25 12:23 ` Eric W. Biederman
2018-10-25 12:23 ` Eric W. Biederman
2018-10-25 12:23 ` Eric W. Biederman
2018-10-25 20:45 ` Enke Chen
2018-10-25 20:45 ` Enke Chen
2018-10-25 21:24 ` Enke Chen
2018-10-25 21:24 ` Enke Chen
2018-10-25 21:56 ` Enke Chen
2018-10-25 21:56 ` Enke Chen
2018-10-25 13:45 ` Jann Horn
2018-10-25 13:45 ` Jann Horn
2018-10-25 20:21 ` Eric W. Biederman
2018-10-25 20:21 ` Eric W. Biederman
2018-10-25 20:21 ` Eric W. Biederman
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=20181015120521.GA10146@redhat.com \
--to=oleg@redhat.com \
--cc=Dave.Martin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christian@brauner.io \
--cc=deller@gmx.de \
--cc=ebiederm@xmission.com \
--cc=enkechen@cisco.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=khalid.aziz@oracle.com \
--cc=kstewart@linuxfoundation.org \
--cc=mchehab+samsung@kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/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.