This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: Rich Felker <dalias at aerifal dot cx>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 29 Nov 2013 14:30:20 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311182312130 dot 8831 at digraph dot polyomino dot org dot uk> <528BA2DA dot 3090608 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311192205550 dot 8742 at digraph dot polyomino dot org dot uk> <20131120204655 dot GL24286 at brightrain dot aerifal dot cx> <5295CD1D dot 7080501 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311271329590 dot 5027 at digraph dot polyomino dot org dot uk> <5295F7A3 dot 9050209 at redhat dot com> <5298243E dot 5050401 at redhat dot com> <20131129175805 dot GF24286 at brightrain dot aerifal dot cx> <20131129192532 dot GA26092 at domone dot podge>
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.
As for SIGEV_THREAD, I don't see how this would simplify
implementation at all.
Rich
- References:
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.