Subject: Re: SA/pthread syscall versioning
To: Christian Limpach <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 12/11/2003 11:55:40
On Dec 11, 4:23pm, email@example.com (Christian Limpach) wrote:
-- Subject: Re: SA/pthread syscall versioning
| From: "Christos Zoulas" <firstname.lastname@example.org>
| > 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
| > 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.