0

My question is about signals and handling them inside the operating system kernel.
I know that every process has it own signal_handler() table: a 31 bit array for signals (pending_signals), and when a signal arrives, do_signal() is invoke, and it calls to the relevant signal_handler() routine, which is running in the user mode and not in the kernel mode (why is that by the way?).

Let's suppose process got some signal i.e. some bit in his signal array is on, who is writing it to this array (I guess it is the process that invoked the signal — the process that we are currently in it's context), therefore, the flow is as follows:

A invokes signal and writes it to B's signal array (before returning to user mode?) Then in the same context (without switching to B) the specific signal handler of this signal of B's is invoked (when do we switch to user mode?) and after we return to A and check if it needs rescheduling and continue…

Second thing is what is happening when the signal is SIG_CHILD, I suppose that it should occur somewhere in do_exit() that is invoked by the child process.

And last thing is how does waitpid(pid_t num) work?
How does the father ignore all the SIG_CHILD signals from its other sons and care only for specific son?

If there is good source for reading the following stuff it will be great (didn't find such).

closed as too broad by Jeff Schaller, X Tian, Stephen Harris, Christopher, Michael Homer Feb 13 at 23:26

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

0

While reading your question. I think you said that the signal handle of B is run in the context of A. This does not sound correct. This would lead to a security loop hole. Signal handlers are always called in the context of the owning process.

This then answers your 2nd part about SIG_CHILD.

You also ask why run signal handles in user space. This is because we don't want to allow processes to inject code into the kernel. If they did, they would be god, of the system.

What process is the signal handler run in?

If a process calls exec, and the code that is loaded contains a signal_handler, and if this signal handler runs, then (like all the other code that was loaded) it is run in this process. You will not find code from one process, unexpectedly, running in another.

  • Ok. so if I got it right when child process dies i.e. becomes zombie it's invokes some routine which switches to it's parent and then turn on the SIG_CHILD bit. in case the father isn't waiting for this process then nothing occurs otherwise it is releases the child task. in case that the function is waitpid() the father turns off the bit on case this process isn't with the pid it is waiting for. by the way what happens after? is the process thst is running is the father process or other process? – michael Feb 12 at 13:37
  • Almost, but it does not run, it only becomes ready to run. When it runs, is up the the process scheduler. – ctrl-alt-delor Feb 12 at 14:26
  • By the way , the signal_handlers are using kernel's data structures and functions by default so why you wrote we don't want the process to inject code into the kernel (why are they different from modules which are act as additional kernel code?) , and if this true then if I override default signal_handler with my own one I can't use the kernel's data within? Another issue that occurred to me is that the process will go to user mode to handle the signal than back to kernel mode and then back to user mode again to run it's user code (in case it isn't terminated) , am I correct? looks like waste – michael Feb 12 at 15:56
  • A user mode accesses kernel made via well defined interfaces. These interfaces are controlled. The kernel decides if it will do what it is asked to do, depending on a users privileges etc. If we could get our own code to run in the kernel, then it would not be subject to these controls. (But all of this is an answer to another question). – ctrl-alt-delor Feb 12 at 20:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.