arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage of ->sighand

[Oleg Nesterov <oleg@redhat.com>]

On 04/18, Oleg Nesterov wrote:
>
> On 04/16, Matt Fleming wrote:
> >
> > 	3. I suspect most people find the rules of ->sighand pretty
> > 	confusing. Just look at
> >
> > 		arch/tile/kernel/hardwall.c:do_hardwall_trap()
> >
> > 	the use of siglock there looks buggy to me.
>
> Indeed, I agree. It shouldn't use __group_send_sig_info() at all.
> I'll send the patch. Nobody outside of signal code should play with
> ->sighand, this is almost always wrong.

Hmm. It turns out, I can't make the patch because I do not understand
what this code tries to do.

hardwall_activate() adds the thread to hardwall_list, but do_hardwall_trap()
sends the signal to the whole process. I know nothing about arch/tile and
probably this is correct, but could you confirm this?

Note that SIGILL can be delivered to another thread in the thread-group, is
it correct?

Also. Is it supposed that SIGILL can have a hanlder or can be blocked, or
it should always kill the whole thread group?

I think we need the patch below, assuming that SIGILL should be sent to
the single thread and it is fine to have a handler for SIGILL.

Oleg.

--- sigprocmask/arch/tile/kernel/hardwall.c~1_sighand	2011-04-06 21:33:42.000000000 +0200
+++ sigprocmask/arch/tile/kernel/hardwall.c	2011-04-21 20:56:36.000000000 +0200
@@ -268,12 +268,10 @@ void __kprobes do_hardwall_trap(struct p
 	found_processes = 0;
 	list_for_each_entry(p, &rect->task_head, thread.hardwall_list) {
 		BUG_ON(p->thread.hardwall != rect);
-		if (p->sighand) {
+		if (!(p->flags & PF_EXITING)) {
 			found_processes = 1;
 			pr_notice("hardwall: killing %d\n", p->pid);
-			spin_lock(&p->sighand->siglock);
-			__group_send_sig_info(info.si_signo, &info, p);
-			spin_unlock(&p->sighand->siglock);
+			do_send_sig_info(info.si_signo, &info, p, false);
 		}
 	}
 	if (!found_processes)