With FreeBSD 8.0 it seems like you can't block pending but undelivered signals

[Richard Sharpe]

On Tue, Jan 8, 2013 at 10:57 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Tue, Jan 08, 2013 at 03:31:58PM -0800, Jeremy Allison wrote:
>> On Tue, Jan 08, 2013 at 03:21:06PM -0800, Richard Sharpe wrote:
>> > On Tue, Jan 8, 2013 at 2:50 PM, Jeremy Allison <jra at samba.org> wrote:
>> > > On Tue, Jan 08, 2013 at 11:15:39AM -0800, Richard Sharpe wrote:
>> > >>
>> > >> OK, it seems that it is not so bad. Based on a response I got from the
>> > >> FreeBSD Hackers mailing list, and some digging, I think the answer is:
>> > >>
>> > >>             sigaddset(&((ucontext_t *)uctx)->uc_sigmask, sig);
>> > >>
>> > >> I will try this soon and get back to you.
>> > >>
>> > >> >From here: http://stackoverflow.com/questions/5531006/returning-from-a-signal-handler-and-leaving-signal-masked
>> > >
>> > > Ok, the correct fix here (and one that will work on Linux too)
>> > > is to ensure we never issue more aio requests than we have
>> > > real-time-signal buckets to receive the responses for them.
>> > >
>> > > i.e. the "100" value inside smbd/aio.c is the real problem
>> > > here, not blocking the rt-signal inside the handler.
>> > >
>> > > Match those sizes and you should not see this error
>> > > occuring.
>> >
>> > Well, that is very true. That was my first approach but I thought
>> > someone was wedded to the notion of using a larger number in the aio
>> > code than the tevent code.
>>
>>
>> No, it's just an accident of history. Changed in one place and
>> not another.
>>
>> > We probably should allow the aio code to fetch the number of buckets
>> > so it never issues more requests than there are bucked available.
>>
>> Indeed - on Linux I think it is impossible for the signal
>> handler function to change the main process mask, it's always
>> restored on return.
>>
>> This means it's an unfixable race condition on Linux (so much
>> for my "what a FreeBSD bug" hypocracy :-), so we really must
>> match these two sizes.
>
> Just a side-note: The code in master and 4.0 is different,
> we do not use the posix API code by default anymore, it is
> only available as a module that you have to explicitly
> select.

Sure, but the bug is in tevent, not really in the code using it. That
is, tevent is doing something that is non-portable and possibly broken
with respect to signals there.

Here is some text from David Xu on the FreeBSD-hackers mailing list on
this subject which suggests that the current implementation in
tevent_signal is wrong.

-------------------------------------------------
The way I introduced is standard:
http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html

I quoted some text here:

When a signal is caught by a signal-catching function installed by
sigaction(), a new signal mask is calculated and installed for the
duration of the signal-catching function (or until a call to either
sigprocmask() or sigsuspend() is made). This mask is formed by taking
the union of the current signal mask and the value of the sa_mask for
the signal being delivered [XSI] [Option Start]  unless SA_NODEFER or
SA_RESETHAND is set, [Option End] and then including the signal being
delivered. If and when the user's signal handler returns normally, the
original signal mask is restored.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

When the signal handler returns, the receiving thread resumes
execution at the point it was interrupted unless the signal handler
makes other arrangements. If longjmp() or _longjmp() is used to leave
the signal handler, then the signal mask must be explicitly restored.

This volume of IEEE Std 1003.1-2001 defines the third argument of a
signal handling function when SA_SIGINFO is set as a void * instead of
a ucontext_t *, but without requiring type checking. New applications
should explicitly cast the third argument of the signal handling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
function to ucontext_t *.
^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)