Messages in this thread | | | Date | Sun, 15 Mar 2009 18:29:26 +0100 | From | Oleg Nesterov <> | Subject | Re: Signal delivery order |
| |
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?
> > 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 can't find how 'handler for "2" will be called first'.
see above,
> Furthermore, if > it's indeed sig_2 that's invoked first then sig_1's sigmask is added to > the current mask upon dequeueing???
sig_1's sigmask was added to ->blocked when we dequeued signal 1.
Oleg.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |