Date: Wed, 09 Jan 2013 20:28:17 -0800 From: Richard Sharpe <rsharpe@richardsharpe.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? Message-ID: <1357792097.8329.9.camel@localhost.localdomain> In-Reply-To: <50ECD0C2.7090801@freebsd.org> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> <50ECD0C2.7090801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2013-01-09 at 10:06 +0800, David Xu wrote:
> [...]
> >>> This code won't work, as I said, after the signal handler returned,
> >>> kernel will copy the signal mask contained in ucontext into kernel
> >>> space, and use it in feature signal delivering.
> >>>
> >>> The code should be modified as following:
> >>>
> >>> void handler(int signum, siginfo_t *info, ucontext_t *uap)
> >>> {
> >>> ...
> >>>
> >>> if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) {
> >>> sigaddset(&uap->uc_sigmask, signum);
> >>
> >> Hmmm, this seems unlikely because the signal handler is operating in
> >> user mode and has no access to kernel-mode variables.
> >
> > Well, it turns out that your suggestion was correct.
> >
> > I did some more searching and found another similar suggestion, so I
> > gave it a whirl, and it works.
> >
> > Now, my problem is that Jeremy Allison thinks that it is a fugly hack.
> > This means that I will probably have big problems getting a patch for
> > this into Samba.
> >
> > I guess a couple of questions I have now are:
> >
> > 1. Is this the same for all versions of FreeBSD since Posix RT Signals
> > were introduced?
> >
>
> I have checked source code, and found from FreeBSD 7.0, RT signal is
> supported, and aio code uses signal queue.
>
> > 2. Which (interpretation of which) combination of standards require such
> > an approach?
> >
> >
> 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 *.
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ---
>
> The above means third parameter is pointing to ucontext_t which is used
> to restored the previously interrupted context, the context contains
> a signal mask which is also restored.
> http://pubs.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html
OK, thank you for that. Jeremy agrees that this is a portable approach,
at least across Linux, FreeBSD and Solaris. We will try to get a fix
into Samba to do it the correct way.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1357792097.8329.9.camel>