On Oct 6,  9:54pm, thorpej@wasabisystems.com (Jason Thorpe) wrote:
-- Subject: Re: SA_SIGINFO notes

I was thinking about following suite with linux and defined
SI_KERNEL as 0x80 and or'ing that in with si_code for kernel
generated signals, but then we'll have to strip the SI_KERNEL
bit before sending siginfo_t to userland. Another way it to
use a separate field, that will have 3 different values:

- caused by a trap
- sent by the kernel, (io, timer, etc.)
- sent from another process

A simpler way, is to have trapsignal assert that si_code > 0,
so that we can simply test for si_code > 0. In this case we
really don't care if the signal came from the kernel or userland
as long as we can tell if the signal was generated by a trap
or not.

christos

| Even ksi_code has to be interpreted in the context of which signal has 
| been generated.  In the old code, "code" being non-zero meant that it 
| was a signal caused by a trap.  In the new code, we don't have an easy 
| way to determine this (note the new ksi_code is not the same as the old 
| "code" .. the old "code" is more like ksi_trap, which is presumably why 
| Christos wrote the new code the way he did, but it has the problems 
| that Paul points out, since it shares storage with other siginfo 
| fields).
| 
| Maybe what we need here is a flag in the ksiginfo_t that says "hey, 
| this is the result of a trap".  Otherwise, we'd have to make a decision 
| based on the *signal*, which isn't even right, since you could e.g. 
| pass SIGSEGV to kill(2).
| 
| There's another use of ksi_code that I think is sketchy.  Take a look 
| at kern_ktrace.c:ktrpsig().  It uses ksi_code > 0 to determine if 
| ksi_trap is valid, but it has the same problem I mention above.  (We 
| need a new ktrace record type that spits out siginfo.)
| 
| Actually, a great example of how using ksi_code in this way falls over 
| is the case of a SIGCHLD being generated because a child exits.  
| ksi_code will be set to CLD_EXITED (1), which will cause ktrpsig() to 
| use ksi_trap, but ksi_trap isn't actually valid, and would overlap with 
| the uid of the exiting process, not the pid.  In any case, 
| historically, the "code" seen in the ktrace record would be 0 in this 
| case, since SIGCHLD isn't generated as the result of a trap.  (I think 
| part of the problem is that we're getting hung up on similar names for 
| things that have very different semantics.)  Matthias's patch would 
| have a similar problem.
| 
|          -- Jason R. Thorpe <thorpej@wasabisystems.com>
-- End of excerpt from Jason Thorpe