On Dec 11,  4:23pm, chris@pin.lu (Christian Limpach) wrote:
-- Subject: Re: SA/pthread syscall versioning

| From: "Christos Zoulas" <christos@zoulas.com>
| > Another issue is passing siginfo_t instead of ksiginfo_t in sa_upcall. We
| > could save the separate pool and the large copy from kernel to userland if
| > we do this, for the tradeoff in some loss of future compatibility, if
| ksiginfo_t
| > grows (which I don't think will happen). What do you think?
| 
| Yes, that would be good.  Actually, there is no compatibility issue because
| in pthread__upcall, the arg pointer is a pointer to the siginfo_t on the
| stack and a larger struct _ksiginfo would still work with an old library.
| It would be good though (since in libpthread we use siginfo_t) to leave
| enough space on the stack to fit a complete siginfo_t and then only copy out
| the currently used part (i.e. struct _ksiginfo).  This would also fix the
| problem that right now we leak unused kernel memory to userspace, because we
| don't clear the padding part of siginfo_t (Yamamoto Takashi mentioned this
| to me in private email).

BTW, this is the case [leaking kernel memory info] in many of the siginfo
machdep.c files (sparc,sparc64,vax, etc.) It did not seem important at
the time, but maybe we should bring it up for discussion again.

christos