> Yes, I also thought about something like this, but tried to avoid because
> it adds some complications. OTOH, this is not the fast path.
I agree it's not real pleasing, and would be glad to find better ideas.
> I'll try to think a bit more about this, and update the patch according
> to your co
hile cleanup to have the logic only in
> get_signal_to_deliver, and to fix the problem you cited. It will take only
> a little extra code to handle the ptrace case too, i.e.
> if (sig_kernel_stop(signr) &&
> current->sighand->action[signr-1] == SIG_DFL &
> Move the setting of SIGNAL_STOP_DEQUEUED from dequeue_signal() to
> get_signal_to_deliver(), and set this flag only if we are really going to
> stop.
> This also simplifies the code and makes the SIGNAL_STOP_DEQUEUED usage more
> understandable.
It looks like a nice cleanup to
but we have to split SIGNAL_STOP_CONTINUED into 2 flags,
> one for do_wait(), another to indicate that do_signal_stop() should abort.
SIGNAL_STOP_DEQUEUED is that second flag (its lack says to abort the stop).
> However, is it all correct currently ? Consider 2 threads, T1 and T2,
> SIGTTIN is
Two threads, T1 and T2, SIGTTIN is SIG_DFL, SIGTTOU has a handler.
T1 does get_signal_to_deliver(), dequeus SIGTTIN, unlocks ->siglock.
SIGCONT comes in, nothing to do yet, just clear SIGNAL_STOP_DEQUEUED.
SIGTTOU is sent, T2 dequeues it and sets SIGNAL_STOP_DEQUE
On 08/27, Roland McGrath wrote:
>
> > But SIGNAL_STOP_DEQUEUED code should be OK, afaics. We only need it to
> > make sure do_signal_stop() can't miss SIGNAL_STOP_CONTINUED/GROUP_EXIT.
> >
> > Can't we remove SIGNAL_STOP_DEQUEUED, btw?
>
&
> But SIGNAL_STOP_DEQUEUED code should be OK, afaics. We only need it to
> make sure do_signal_stop() can't miss SIGNAL_STOP_CONTINUED/GROUP_EXIT.
>
> Can't we remove SIGNAL_STOP_DEQUEUED, btw?
No, we can't.
> dequeue_signal:
>
>
7 matches
Mail list logo
