> The freezer is crap... news at 11. Maybe a quick hack would be to let it
> clear sigpending if tsk->mm == NULL but that's ugly. Note that there's
> anything pretty about the freezer anyway...
I think it might be made not too unreasonable by adding a TASK_FROZEN state.
But I am still persuaded by my "hide in the corner" plan.
> Well.. why was it _and_wake() in the first place anyway ? Or do I miss
> something ? Why would we need to wake a thread for which we are removing
> signals ?
The bug was about a case where recalc_sigpending_tsk would set
TIF_SIGPENDING when it hadn't been set before (wants_signal). It has
nothing to do with the rm_from_queue_full being done there. It's just a
violation of the necessary rule that when you set TIF_SIGPENDING on another
thread you better call signal_wake_up on it.
> What about something like:
>
> do {
> rm_from_queue_full(&mask, &t->pending);
> - recalc_sigpending_and_wake(t);
> t = next_thread(t);
> } while (t != current);
> + recalc_sigpending();
There is no need for the +, just the -. The calling thread is the one
where know there is certainly no perturbation of behavior due to leaving
TIF_SIGPENDING set rather than clearing it. It's just going to exit the
syscall and deal with signal state properly on the way out either way.
Doing recalc_sigpending is an unnecessary optimization of the corner case.
> So at the end of the day, easier to test it inside dequeue_signal().
Before completely revamping the whole set of entrypoints to be saner all
around, yes.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
