linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Enke Chen <enkechen@cisco.com>
To: Jann Horn <jannh@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <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>,
	deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Dave.Martin@arm.com, mchehab+samsung@kernel.org,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	"Kirill A . Shutemov" <kirill.sh>
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 15 Oct 2018 11:36:19 -0700	[thread overview]
Message-ID: <c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com> (raw)
In-Reply-To: <CAG48ez2ZPhnxudqgU7nC2ORvLnS0Ja-qhLSE5WAY361jst7XNw@mail.gmail.com>

Hi, Jann:

Thanks a lot for you detailed review. Please see my replied/comments inline.

On 10/13/18 11:27 AM, Jann Horn wrote:
> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen <enkechen@cisco.com> 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.
> 
> Your suggested API looks vaguely similar to PR_SET_PDEATHSIG, but with
> some important differences:
> 
>  - You don't reset the signal on setuid execution.
>  - You permit setting this not just on the current process, but also on others.
> 
> For both of these: Are these differences actually necessary, and if
> so, can you provide a specific rationale? From a security perspective,
> I would very much prefer it if this API had semantics closer to
> PR_SET_PDEATHSIG.

Regarding setting on others, I started with setting for self. But there is
a requirement for supporting the feature for a process manager written in
bash script. That's the reason for allowing the setting on others.

Given the feedback from you and others, I agree that it would be simpler and
more secure to remove the setting on others. We can submit a patch for bash
to support the setting natively.

Regarding the impact of "setuid", this property "PR_SET_PREDUMP_SIG" has to
do with the application/process whether the signal handler is set for receiving
such a notification.  If it is set, the "uid" should not matter.

> 
> [...]
>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index 312b43e..eb4a483 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2337,6 +2337,44 @@ static int ptrace_signal(int signr, kernel_siginfo_t *info)
>>         return signr;
>>  }
>>
>> +/*
>> + * Let the parent, if so desired, know about the imminent death of a child
>> + * prior to its coredump.
>> + *
>> + * Locking logic is similar to do_notify_parent_cldstop().
>> + */
>> +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;
>> +       sig = parent->predump_signal;
>> +
>> +       /* Check again with "tasklist_lock" locked by the caller */
>> +       if (!valid_predump_signal(sig))
>> +               return;
>> +
>> +       clear_siginfo(&info);
>> +       info.si_signo = sig;
>> +       if (sig == SIGCHLD)
>> +               info.si_code = CLD_PREDUMP;
>> +
>> +       rcu_read_lock();
>> +       info.si_pid = task_pid_nr_ns(tsk, task_active_pid_ns(parent));
>> +       info.si_uid = from_kuid_munged(task_cred_xxx(parent, user_ns),
>> +                                      task_uid(tsk));
> 
> You're sending a signal from the current namespaces, but with IDs that
> have been mapped into the parent's namespaces? That looks wrong to me.

I am following the example "do_notify_parent_cldstop()" called in the same
routine "get_signal()". If there is a better way, sure I will use it.

> 
>> +       rcu_read_unlock();
>> +
>> +       sighand = parent->sighand;
>> +       spin_lock_irqsave(&sighand->siglock, flags);
>> +       __group_send_sig_info(sig, &info, parent);
>> +       spin_unlock_irqrestore(&sighand->siglock, flags);
>> +}
>> +
>>  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;
> 
> current->real_parent is an __rcu member. I think if you run the sparse
> checker against this patch, it's going to complain. Are you allowed to
> access current->real_parent in this context?

Let me check, and get back to you on this one.

> 
>> +                       if (valid_predump_signal(p_sig)) {
>> +                               read_lock(&tasklist_lock);
>> +                               do_notify_parent_predump(current);
>> +                               read_unlock(&tasklist_lock);
>> +                               cond_resched();
>> +                       }
>> +
>>                         if (print_fatal_signals)
>>                                 print_fatal_signal(ksig->info.si_signo);
>>                         proc_coredump_connector(current);
>> diff --git a/kernel/sys.c b/kernel/sys.c
>> index 123bd73..43eb250d 100644
>> --- a/kernel/sys.c
>> +++ b/kernel/sys.c
>> @@ -2258,6 +2258,76 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which,
>>         return -EINVAL;
>>  }
>>
>> +static int prctl_get_predump_signal(struct task_struct *tsk, pid_t pid,
>> +                                   int __user *addr)
>> +{
>> +       struct task_struct *p;
>> +       int error;
>> +
>> +       /* For the current task, the common case */
>> +       if (pid == 0) {
>> +               put_user(tsk->predump_signal, addr);
>> +               return 0;
>> +       }
>> +
>> +       error = -ESRCH;
>> +       rcu_read_lock();
>> +       p = find_task_by_vpid(pid);
>> +       if (p) {
>> +               error = 0;
>> +               put_user(p->predump_signal, addr);
> 
> This is wrong. You can't call put_user() while you're in an RCU
> read-side critical section.
> 
> As below, I would like it if you could just get rid of this branch,
> and restrict this prctl to operating on the current process.

My bad. The code will be removed.

> 
>> +       }
>> +       rcu_read_unlock();
>> +       return error;
>> +}
>> +
>> +/*
>> + * Returns true if current's euid is same as p's uid or euid,
>> + * or has CAP_SYS_ADMIN.
>> + *
>> + * Called with rcu_read_lock, creds are safe.
>> + *
>> + * Adapted from set_one_prio_perm().
>> + */
>> +static bool set_predump_signal_perm(struct task_struct *p)
>> +{
>> +       const struct cred *cred = current_cred(), *pcred = __task_cred(p);
>> +
>> +       return uid_eq(pcred->uid, cred->euid) ||
>> +              uid_eq(pcred->euid, cred->euid) ||
>> +              capable(CAP_SYS_ADMIN);
>> +}
> 
> This permission check permits fiddling with other processes in
> scenarios where kill() wouldn't let you send signals (specifically, if
> you control the EUID of the target task). That worries me. Also,
> kill() is subject to LSM checks (see check_kill_permission()), but
> this interface isn't. I would really prefer it if you could amend this
> so that you can only operate on the current task, and get rid of this
> permission check.

It is gone.

> 
> [...]
>>  SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>>                 unsigned long, arg4, unsigned long, arg5)
>>  {
>> @@ -2476,6 +2546,13 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which,
>>                         return -EINVAL;
>>                 error = arch_prctl_spec_ctrl_set(me, arg2, arg3);
>>                 break;
>> +       case PR_SET_PREDUMP_SIG:
>> +               error = prctl_set_predump_signal(me, (pid_t)arg2, (int)arg3);
>> +               break;
>> +       case PR_GET_PREDUMP_SIG:
>> +               error = prctl_get_predump_signal(me, (pid_t)arg2,
>> +                                                (int __user *)arg3);
>> +               break;
> 
> New prctl() calls should check that the unused arguments are zero, in
> order to make it possible to safely add more flags in the future.

Will do.

Thanks again.  -- Enke

WARNING: multiple messages have this Message-ID (diff)
From: Enke Chen <enkechen@cisco.com>
To: Jann Horn <jannh@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <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>,
	deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Dave.Martin@arm.com, mchehab+samsung@kernel.org,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	guro@fb.com, marcos.souza.org@gmail.com,
	Oleg Nesterov <oleg@redhat.com>,
	linux@dominikbrodowski.net, Cyrill Gorcunov <gorcunov@openvz.org>,
	yang.shi@linux.alibaba.com, Kees Cook <keescook@chromium.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	kamensky@cisco.com, xe-linux-external@cisco.com,
	sstrogin@cisco.com, Enke Chen <enkechen@cisco.com>
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 15 Oct 2018 11:36:19 -0700	[thread overview]
Message-ID: <c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com> (raw)
Message-ID: <20181015183619.DbK2i4nEVYeR7yv7yFf0ELLYd1eQAOzn02wMGyQbrug@z> (raw)
In-Reply-To: <CAG48ez2ZPhnxudqgU7nC2ORvLnS0Ja-qhLSE5WAY361jst7XNw@mail.gmail.com>

Hi, Jann:

Thanks a lot for you detailed review. Please see my replied/comments inline.

On 10/13/18 11:27 AM, Jann Horn wrote:
> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen <enkechen@cisco.com> 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.
> 
> Your suggested API looks vaguely similar to PR_SET_PDEATHSIG, but with
> some important differences:
> 
>  - You don't reset the signal on setuid execution.
>  - You permit setting this not just on the current process, but also on others.
> 
> For both of these: Are these differences actually necessary, and if
> so, can you provide a specific rationale? From a security perspective,
> I would very much prefer it if this API had semantics closer to
> PR_SET_PDEATHSIG.

Regarding setting on others, I started with setting for self. But there is
a requirement for supporting the feature for a process manager written in
bash script. That's the reason for allowing the setting on others.

Given the feedback from you and others, I agree that it would be simpler and
more secure to remove the setting on others. We can submit a patch for bash
to support the setting natively.

Regarding the impact of "setuid", this property "PR_SET_PREDUMP_SIG" has to
do with the application/process whether the signal handler is set for receiving
such a notification.  If it is set, the "uid" should not matter.

> 
> [...]
>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index 312b43e..eb4a483 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2337,6 +2337,44 @@ static int ptrace_signal(int signr, kernel_siginfo_t *info)
>>         return signr;
>>  }
>>
>> +/*
>> + * Let the parent, if so desired, know about the imminent death of a child
>> + * prior to its coredump.
>> + *
>> + * Locking logic is similar to do_notify_parent_cldstop().
>> + */
>> +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;
>> +       sig = parent->predump_signal;
>> +
>> +       /* Check again with "tasklist_lock" locked by the caller */
>> +       if (!valid_predump_signal(sig))
>> +               return;
>> +
>> +       clear_siginfo(&info);
>> +       info.si_signo = sig;
>> +       if (sig == SIGCHLD)
>> +               info.si_code = CLD_PREDUMP;
>> +
>> +       rcu_read_lock();
>> +       info.si_pid = task_pid_nr_ns(tsk, task_active_pid_ns(parent));
>> +       info.si_uid = from_kuid_munged(task_cred_xxx(parent, user_ns),
>> +                                      task_uid(tsk));
> 
> You're sending a signal from the current namespaces, but with IDs that
> have been mapped into the parent's namespaces? That looks wrong to me.

I am following the example "do_notify_parent_cldstop()" called in the same
routine "get_signal()". If there is a better way, sure I will use it.

> 
>> +       rcu_read_unlock();
>> +
>> +       sighand = parent->sighand;
>> +       spin_lock_irqsave(&sighand->siglock, flags);
>> +       __group_send_sig_info(sig, &info, parent);
>> +       spin_unlock_irqrestore(&sighand->siglock, flags);
>> +}
>> +
>>  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;
> 
> current->real_parent is an __rcu member. I think if you run the sparse
> checker against this patch, it's going to complain. Are you allowed to
> access current->real_parent in this context?

Let me check, and get back to you on this one.

> 
>> +                       if (valid_predump_signal(p_sig)) {
>> +                               read_lock(&tasklist_lock);
>> +                               do_notify_parent_predump(current);
>> +                               read_unlock(&tasklist_lock);
>> +                               cond_resched();
>> +                       }
>> +
>>                         if (print_fatal_signals)
>>                                 print_fatal_signal(ksig->info.si_signo);
>>                         proc_coredump_connector(current);
>> diff --git a/kernel/sys.c b/kernel/sys.c
>> index 123bd73..43eb250d 100644
>> --- a/kernel/sys.c
>> +++ b/kernel/sys.c
>> @@ -2258,6 +2258,76 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which,
>>         return -EINVAL;
>>  }
>>
>> +static int prctl_get_predump_signal(struct task_struct *tsk, pid_t pid,
>> +                                   int __user *addr)
>> +{
>> +       struct task_struct *p;
>> +       int error;
>> +
>> +       /* For the current task, the common case */
>> +       if (pid == 0) {
>> +               put_user(tsk->predump_signal, addr);
>> +               return 0;
>> +       }
>> +
>> +       error = -ESRCH;
>> +       rcu_read_lock();
>> +       p = find_task_by_vpid(pid);
>> +       if (p) {
>> +               error = 0;
>> +               put_user(p->predump_signal, addr);
> 
> This is wrong. You can't call put_user() while you're in an RCU
> read-side critical section.
> 
> As below, I would like it if you could just get rid of this branch,
> and restrict this prctl to operating on the current process.

My bad. The code will be removed.

> 
>> +       }
>> +       rcu_read_unlock();
>> +       return error;
>> +}
>> +
>> +/*
>> + * Returns true if current's euid is same as p's uid or euid,
>> + * or has CAP_SYS_ADMIN.
>> + *
>> + * Called with rcu_read_lock, creds are safe.
>> + *
>> + * Adapted from set_one_prio_perm().
>> + */
>> +static bool set_predump_signal_perm(struct task_struct *p)
>> +{
>> +       const struct cred *cred = current_cred(), *pcred = __task_cred(p);
>> +
>> +       return uid_eq(pcred->uid, cred->euid) ||
>> +              uid_eq(pcred->euid, cred->euid) ||
>> +              capable(CAP_SYS_ADMIN);
>> +}
> 
> This permission check permits fiddling with other processes in
> scenarios where kill() wouldn't let you send signals (specifically, if
> you control the EUID of the target task). That worries me. Also,
> kill() is subject to LSM checks (see check_kill_permission()), but
> this interface isn't. I would really prefer it if you could amend this
> so that you can only operate on the current task, and get rid of this
> permission check.

It is gone.

> 
> [...]
>>  SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>>                 unsigned long, arg4, unsigned long, arg5)
>>  {
>> @@ -2476,6 +2546,13 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which,
>>                         return -EINVAL;
>>                 error = arch_prctl_spec_ctrl_set(me, arg2, arg3);
>>                 break;
>> +       case PR_SET_PREDUMP_SIG:
>> +               error = prctl_set_predump_signal(me, (pid_t)arg2, (int)arg3);
>> +               break;
>> +       case PR_GET_PREDUMP_SIG:
>> +               error = prctl_get_predump_signal(me, (pid_t)arg2,
>> +                                                (int __user *)arg3);
>> +               break;
> 
> New prctl() calls should check that the unused arguments are zero, in
> order to make it possible to safely add more flags in the future.

Will do.

Thanks again.  -- Enke

  parent reply	other threads:[~2018-10-15 18:36 UTC|newest]

Thread overview: 140+ 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-13 18:27 ` Jann Horn
2018-10-13 18:27   ` Jann Horn
2018-10-15 18:36   ` Enke Chen [this message]
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
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-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-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-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 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 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

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=c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com \
    --to=enkechen@cisco.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=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jannh@google.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=riel@surriel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).