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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>