lkml.org 
[lkml]   [2016]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v12 04/13] task_isolation: add initial support
On Wed, May 18, 2016 at 12:34:22PM -0400, Chris Metcalf wrote:
> On 5/18/2016 9:34 AM, Peter Zijlstra wrote:
> >On Tue, Apr 05, 2016 at 01:38:33PM -0400, Chris Metcalf wrote:
> >>diff --git a/kernel/signal.c b/kernel/signal.c
> >>index aa9bf00749c1..53e4e62f2778 100644
> >>--- a/kernel/signal.c
> >>+++ b/kernel/signal.c
> >>@@ -34,6 +34,7 @@
> >> #include <linux/compat.h>
> >> #include <linux/cn_proc.h>
> >> #include <linux/compiler.h>
> >>+#include <linux/isolation.h>
> >> #define CREATE_TRACE_POINTS
> >> #include <trace/events/signal.h>
> >>@@ -2213,6 +2214,9 @@ relock:
> >> /* Trace actually delivered signals. */
> >> trace_signal_deliver(signr, &ksig->info, ka);
> >>+ /* Disable task isolation when delivering a signal. */
> >Why !? Changelog is quiet on this.
>
> There are really two reasons.
>
> 1. If the task is receiving a signal, it will know it's not isolated
> any more, so we don't need to worry about notifying it explicitly.
> This behavior is easy to document and allows the application to decide
> if the signal is unexpected and it should go straight to its error
> handling path (likely outcome, and in that case you want task isolation
> off anyway) or if it thinks it can plausibly re-enable isolation and
> return to where the signal interrupted you at (hard to imagine how this
> would ever make sense, but you could if you wanted to).
>
> 2. When we are delivering a signal we may already be holding the lock
> for the signal subsystem, and it gets hard to figure out whether it's
> safe to send another signal to the application as a "task isolation
> broken" notification. For example, sending a signal to a task on
> another core involves doing an IPI to that core to kick it; the IPI
> normally is a generic point for notifying the remote core of broken
> task isolation and sending a signal - except that at the point where
> we would do that on the signal path we are already holding the lock,
> so we end up deadlocked. We could no doubt work around that, but it
> seemed cleaner to decouple the existing signal mechanism from the
> signal delivery for task isolation.
>
> I will add more discussion of the rationale to the commit message.

Please also expand the in-code comment, as that is what we'll see first
when reading the code.

\
 
 \ /
  Last update: 2016-05-18 19:41    [W:0.050 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site