signal

signal

Post by Fritz » Wed, 11 Jun 2003 00:10:44




> If my process call a system call and already in kernal mode.
> then I send a kill -9 to my process.
> The system will change to user mode and recive the signal?

Signal delivery occurs by setting a bit in the uarea structure associated
with the process.  Typically, checks for posted signals (i.e. looking at
the signal flag in uarea) occur at return from a system call, return from a
trap, and wakeup from sleep.

If your process is in the kernel during a system call, kill -9 will not
interrrupt the system call unless there is code which specifically tests
for signals (i.e. while the system call is waiting for an event).

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
                4=a  0=o  3=e  +=t

 
 
 

signal

Post by Amri » Wed, 11 Jun 2003 13:00:36




> > If my process call a system call and already in kernal mode.
> > then I send a kill -9 to my process.
> > The system will change to user mode and recive the signal?

> Signal delivery occurs by setting a bit in the uarea structure associated
> with the process.  Typically, checks for posted signals (i.e. looking at
> the signal flag in uarea) occur at return from a system call, return from a
> trap, and wakeup from sleep.

> If your process is in the kernel during a system call, kill -9 will not
> interrrupt the system call unless there is code which specifically tests
> for signals (i.e. while the system call is waiting for an event).

> RFM

One doubt:-

i think, if the current system call getting executed in the kernel
mode, itself generates the -9 signal (bad argument). Then this process
will be able to handle, this new signal

Amrith

 
 
 

signal

Post by Fritz » Thu, 12 Jun 2003 08:12:00



> i think, if the current system call getting executed in the kernel
> mode, itself generates the -9 signal (bad argument). Then this process
> will be able to handle, this new signal

I don't see that; my strong suspicion is that the signal flag is set in the
process uarea.

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
                4=a  0=o  3=e  +=t

 
 
 

signal

Post by Fritz » Wed, 18 Jun 2003 07:58:04



> i think, if the current system call getting executed in the kernel
> mode, itself generates the -9 signal (bad argument).

Amrith,

It just occurred to me that you might have meant "bad argument to a
function."

If you do something in the kernel that results in a fault (e.g. NULL
pointer dereference or reference to non-existent memory location), the
result is a system panic.

RFM

 
 
 

signal

Post by Amri » Wed, 18 Jun 2003 12:12:15


Fritz.

System panic is rare case, since OS will validate the arguments in the
registers before executing the system call handler.

Amrith

 
 
 

1. Signal handlers are not reset after signal delivery

The man page for signal says

        Unlike on BSD systems, signals under Linux  are  reset  to
        their  default behavior  when  raised.  However, if you
        include <bsd/signal.h> instead of <signal.h> then signal is
        redefined as __bsd_signal and signal has the BSD
semantics.

However I tried the following simple program and found that if I install
a signal handler once, it remains installed over multiple deliveries of
the same signal. i.e. the signal does not get  reset to its default
behaviour when raised.

#include <stdio.h>
#include <signal.h>

void  handler( int x) {

        printf( "Got the signal\n");

main() {

        char c;
        signal(28, handler);

        sleep(3600);

        printf( "Woke up\n");
        sleep(3600);

and the I did 'kill -28 <pid>' twice. Both the times I got the
message from signal handler.

Can anyone help explain this contradiction or am I messing up
somewhere in the concepts?

Thanks,
-Kartik

2. wait/trap/kill/tail weirdness

3. Signal handling: signal() vs. sigaction()

4. le0: No carrier - cable disconnected or hub link test disable?

5. blocking signals in signal handler -- True or False quiz

6. backspace delete termcap...

7. ** POSIX signals limited to 32 signals?

8. DEC Tulip Drivers in Kernel?

9. Registering signal inside signal handler

10. signal.c: wrong rt signals comment, 2.4.20-pre11

11. signal inside signal

12. trap "<new trap action>; $(get_old_trap SIGNAL)" SIGNAL

13. Registering client data on signal manager side andreceiving it in signal handler