lkml.org 
[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: checksignals hackery?


On Sat, 5 Sep 1998, Richard Henderson wrote:
>
> void checksignals(void)
> {
> sigset_t *blocked = &current->blocked;
> unsigned long mask = blocked->sig[0] | sigmask(SIGKILL) | sigmask(SIGINT) | sigmask(SIGQUIT);
> mask &= blocked->sig[1];
> if (~mask) {
> printk("Bad signal mask\n");
> *(int *) 0 = 0;
> }
> }
>
> It seems to be confused wrt sig[1]. Should that have been
> an IOR instead of an AND?

No.

The thing makes sure that the blocked set contains _everything_ except for
SIGKILL/SIGINT/SIGQUIT, because the RPC code really wouldn't work if there
are other signals that could come through.

So the "and" is there to make sure that all bits are set.

> And why, if it is important at all, it was implemented in
> arch/i386/kernel/signal.c rather than kernel/signal.c? Is
> this just some big of debug hackery that was accidentally
> left in?

It wasn't exactly accidental, and it already found one case where we
allowed signals we really didn't want to allow. But yes, it's debugging
code, and I expect to remove it very shortly when I feel comfortable that
all NFS paths do indeed block signals properly..

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.035 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site