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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Rich Felker <dalias at aerifal dot cx>
- Cc: "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: Tue, 03 Dec 2013 10:27:08 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com> <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> <529DE17E dot 7010105 at redhat dot com>
On 12/03/2013 08:49 AM, Florian Weimer wrote:
> On 11/29/2013 06:58 PM, Rich Felker wrote:
>> On Fri, Nov 29, 2013 at 12:21:02AM -0500, Carlos O'Donell wrote:
>>> 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.
>
> What should we do about this? Try to get clarification from Austin
> Group first what's the intended behavior here, or if they intend to
> specify a certain behavior in the future?
>
I think that's certainly the right start. File a defect with the
Austin Group tracker and ask them the following things:
* What if any unintended consequences could there be if the
implementation choose to save and restore errno during
signal handling?
* Was it ever POSIX's intent to allow a signal handler to
modify the errno of the interrupted code sequence or was
that simply a consequence of being a signal handler and
modifying global state?
... and anything else you think we should get an expert opinion
on before embarking upon a change like this.
Cheers,
Carlos.