On Fri, May 1, 2015 at 8:37 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > "flush_signals()" is only for kernel threads, where it's a hacky > alternative to actually handling them (since kernel threads never > rreturn to user space and cannot really "handle" a signal). But you're > doing it in the ->remove handler for the device, which can be called > by arbitrary system processes. This is not a kernel thread thing, as > far as I can see. > > If you cannot handle signals, you damn well shouldn't be using > "wait_event_interruptible_timeout()" to begin with. Get rid of the > "interruptible", since it apparently *isn't* interruptible. > > So I'm not pulling this. > > Now I'm worried that other drivers do insane things like this. I > wonder if we should add some sanity test to flush_signals() to make > sure that it can only ever get called from a kernel thread. Hmm, a quick grep exposes some questionable users. At least w1 looks fishy. drivers/w1/w1_family.c:w1_unregister_family drivers/w1/w1_int.c:__w1_remove_master_device What do you think about a WARN_ON like: diff --git a/kernel/signal.c b/kernel/signal.c index d51c5dd..b4079c3 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -427,6 +427,8 @@ void flush_signals(struct task_struct *t) { unsigned long flags; + WARN_ON((current->flags & PF_KTHREAD) == 0); + spin_lock_irqsave(&t->sighand->siglock, flags); __flush_signals(t); spin_unlock_irqrestore(&t->sighand->siglock, flags); -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html