> 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
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
p 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
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 SIG_DFL, SIGTTOU has a handler.
T1
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 me.
However
case too, i.e.
if (sig_kernel_stop(signr)
current-sighand-action[signr-1] == SIG_DFL
!(current-signal-flags SIGNAL_GROUP_EXIT))
current-signal-flags |= SIGNAL_STOP_DEQUEUED;
ptrace_stop(signr, signr, info);
if (sig_kernel_stop(signr) current
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?
>
> No, we
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?
No, we can't.
dequeue_signal
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_DEQUEUED
> 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:
>
> if
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:
if (sig_kernel_stop(sig
14 matches
Mail list logo
