Subject: Re: SA_SIGINFO notes
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 10/06/2003 03:07:49
In article <200310052133.h95LXKR15091@sam.few.eur.nl>,
Paul Kranenburg <pk@cs.few.eur.nl> wrote:
>The kernel bits for SIGINFO support for the sparc are there.

Thanks for doing this!

>Two things that I noticed while working on this:
>
>1. The i386 port supports clearing the SS_ONSTACK bit in setmcontext()
>   through the use of private flags (UC_SETSTACK/UC_CLRSTACK). The
>   vax port appears not to reset SS_ONSTACK at all.
>
>   Would it make sense to move UC_{SET,CLR}STACK to the MI ucontext.h
>   header so all ports can use this mechanism; possibly even by doing
>   it in kern_sig.c:setucontext().

I don't know. I did the i386 port and I tried to preseve the stack semantics
of the old signal handlers. I am not sure if that should become MI, but
we need to look at a better way of fixing it without causing code duplication.
There are comments in the get/set context calls that show that we need to
improve in this area.

>  
>
>2. In kern_sig.c:kpsendsig(), the `ksi_trap' is used to decide which
>   arguments to pass to sa_upcall(). I don't what it is used for,
>   but blindly using `ksi_trap' without further inspection of the
>   siginfo context seems like a bad idea. `ksi_trap' is only defined
>   for certain signal numbers, and its contents is MD even then.
>   E.g. it might just be file descriptor 0 in a SIGPOLL delivery, or
>   the user id of a process in a SIGCLD.. who knows?

Yes, this is wrong. It was wrong initially because it was just using the
trap argument that happened to always be 0 on a non trap generated signal
(either a signal sent by a userland process, or by the kernel on a timer
or io event). I think that the code wants to send a trap to the particular
lwp that got the trap, otherwise it can send it to any lwp. 

christos