Re: Consensus on MT-, AS- and AC-Safety docs.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, Nov 29, 2013 at 02:30:20PM -0500, Rich Felker wrote:
> On Fri, Nov 29, 2013 at 08:25:32PM +0100, OndÅej BÃlka wrote:
> > On Fri, Nov 29, 2013 at 12:58:05PM -0500, Rich Felker wrote:
> > > On Fri, Nov 29, 2013 at 12:21:02AM -0500, Carlos O'Donell wrote:
> > > > On 11/27/2013 08:46 AM, Florian Weimer wrote:
> > > > > On 11/27/2013 02:34 PM, Joseph S. Myers wrote:
> > > > >> On Wed, 27 Nov 2013, Florian Weimer wrote:
> > > > >>> I think we should do that in the code that wraps the signal
> > > > >>> handler call, to address this class of errors once and for all.
> > > > >>> Is this feasible?
> > > > >> 
> > > > >> On many architectures the signal trampoline is provided by the
> > > > >> kernel and so has no access to libc implementation details like
> > > > >> errno.  As far as I understand, even when provided by libc all it
> > > > >> does is call the sigreturn syscall and provide appropriate unwind
> > > > >> information for the registers the kernel saved on the stack - that
> > > > >> is, there is no userspace code called before the signal handler
> > > > >> that would have a chance to save errno.
> > > > > 
> > > > > The number of signals is fixed and small, so it should be feasible to
> > > > > install our own handler in the kernel and store the user-supplied
> > > > > handler in a lookup table that gets called from our handler.  There
> > > > > might be a slight performance impact, though.
> > > > > 
> > > > > But if we think this errno issue is serious, rather than patching
> > > > > almost any signal handler out there right now, we should address it
> > > > > in glibc.
> > > > 
> > > > All we need to do is extend the kernel infrastructure to create
> > > > a signal entry trampoline like it does for signal return. This isn't
> > > > impossible, but requires work.
> > > 
> > > Kernel help is not required for this. You just set set the signal
> > > handler address to your wrapper in libc when making the rt_sigaction
> > > syscall, and then have the wrapper call the real signal handler
> > > function, whose address is stored in userspace. There are some nasty
> > > atomicity/synchronization issues to cover with the race window between
> > > the rt_sigaction syscall (which might change flags affecting how the
> > > signal handler runs even though the new handler address will always be
> > > the same) and replacing the pointer in userspace, and keeping this
> > > entire operation AS-safe, but I'm pretty sure it's possible.
> > > 
> > Well with changing kernel it suffices to add a void * field extra to
> > sigaction, siginfo and sigevent structures and make kernel write into
> > siginfo value that was passed in sigaction.
> 
> This could be done, but it's not necessary. I'm almost sure the kernel
> folks would reject it because the same thing can be done purely in
> userspace with no extra field passed to the kernel.
> 
> > We could pass real siginfo structure in this argument and call
> > appropriate function.
> > 
> > This would allow adding flags that can be implemented solely in
> > userspace, also ON_STACK, SIGEV_THREAD could be implemented without
> > kernel involvement.
> 
> ON_STACK definitely cannot be implemented in userspace. The whole
> point is, at the time of the signal, the stack pointer may be invalid
> (for example, due to stack overflow or a signal occurring during asm
> that's misappropriated the stack pointer for some other purpose, or
> code running on a stack that's too small to hold a signal frame). The
> kernel must be responsible for setting up the alternate stack pointer
> when invoking the signal handler.
>
You are first telling that signal handling can be done in userspace by
racefree manner and that ON_STACK cannot be. Could you clarify how to
handle race when installing ON_STACK handler?