From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 04:28:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10734ED for ; Thu, 10 Jan 2013 04:28:28 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 934481D0 for ; Thu, 10 Jan 2013 04:28:27 +0000 (UTC) Received: (qmail 77670 invoked by uid 89); 10 Jan 2013 04:28:20 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 10 Jan 2013 04:28:20 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: David Xu 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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jan 2013 20:28:17 -0800 Message-ID: <1357792097.8329.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 04:28:28 -0000 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.