2009/3/17 Subrata Modak <[email protected]>: > Hi Gábor, > > On Mon, Mar 16, 2009 at 3:36 AM, Gábor Melis <[email protected]> wrote: >> >> On Domingo 15 Marzo 2009, Oleg Nesterov wrote: >> > On 03/15, Gábor Melis wrote: >> > > On Domingo 15 Marzo 2009, Oleg Nesterov wrote: >> > > > If test_signal (SIGUSR1) is blocked, this means it is already >> > > > delivered, and the handler will be invoked when we return from >> > > > sigsegv_handler(), please see below. >> > > >> > > SIGUSR1 is delivered, its sigmask is added to the current mask but >> > > the handler is not yet invoked and in this instant synchronous >> > > sigsegv is delivered, its handler invoked? >> > >> > Can't understand the question. Could you reiterate? >> >> No need, my question was answered below. >> >> > > > When sigprocmask(SIG_UNBLOCK) returns, both signals are >> > > > delivered. The kernel deques 1 first, then 2. This means that the >> > > > handler for "2" will be called first. >> > > >> > > My mental model that matches what I quickly glean from the sources >> > > (from kernel/signal.c, arch/x86/kernel/signal_32.c) goes like this: >> > > >> > > - signal 1 and signal 2 are generated and made pending >> > > - they are unblocked by sigprocmask >> > > - signal 1 is delivered: signals in its mask (only itself here) are >> > > blocked >> > >> > yes. >> > >> > the kernel changes ip (instruction pointer) to sig_1. >> > >> > > its handler is invoked >> > >> > no. >> > >> > We never return to user-space with a pending signal. We dequeue >> > signal 2 too, and change ip to sig_2. >> > >> > Now, since there are no more pending signals, we return to the user >> > space, and start sig_2(). >> >> I see. I guess in addition to changing the ip, the stack frobbing magic >> arranges that sig_2 returns to sig_1 or some code that calls sig_1. >> >> >From the point of view of sig_2 it seems that sig_1 is already invoked >> because it has its sigmask in effect and the ip in the ucontext of >> sig_2 points to sig_1 as the attached signal-test.c shows: >> >> sig_1=80485a7 >> sig_2=80485ed >> 2 1 >> eip: 80485a7 >> 1 0 >> eip: b7fab424 >> >> The revised signal-delivery-order.c (also attached) outputs: > > Our Project does Kernel Testing (http://ltp.sourceforge.net/). I was > watching this thread and found the discussion interesting. Could you please > tell us, whether these test programs are dependent on each other, or they > need to be executed separately to produce 2 different outputs, and then > compare these outputs for conclusion. With your permission we would like to > add these tests(under GPL) in to our automated test environment. Could you > help us here ?
Subrata, I think I understand all the details that Gabor and Oleg are referring to, but I'm wondering what you hope is testable here. Much of this is implementation-specific detail. For example, if two signals are pending, POSIX.1 does not mandate the order in which they are delivered (unless they are real-time signals). POSIX.1 doesn't even require that both signals will be delivered. Here the text from the specification of sigprocmask(): # If there are any pending unblocked signals after # the call to sigprocmask( ), at least one of those # signals shall be delivered before the call to # sigprocmask( ) returns. So I'm not sure that Gabor's tests would be useful in LTP. Cheers, Michael ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
