Messages in this thread |  | | Date | Thu, 26 Feb 2009 21:36:53 +0100 | | From | Oleg Nesterov <> | | Subject | Re: [RFC][PATCH] signals: don't copy siginfo_t on dequeue |
| |
On 02/26, Vegard Nossum wrote: > > 2009/2/26 Oleg Nesterov <oleg@redhat.com>: > > So. dequeue_signal() returns NULL if there is no siginfo queued. In that > > case we assume that the signal is not pending. > > > > But this is not right. Think about SEND_SIG_FORCED, or __sigqueue_alloc() > > failure when the signal is sent. Or look at zap_other_threads() for example, > > it just sets the bit in ->pending but doesn't queue siginfo. > > I will investigate.
Cough. Well, I must admit I am a bit skeptical about this patch ;) Because I suspect it will add more complications to the code. And _I think_ avoiding copy_siginfo() does not buy too much. I will be happy if I am wrong, though.
But. If you are going to do another version, then please note there is another problem with this patch, SIGQUEUE_PREALLOC.
If collect_signal() returns SIGQUEUE_PREALLOC info, we can not drop ->siglock. I mean, once we drop ->siglock, this info can be freed, so for example
spin_unlock(&tsk->sighand->siglock); - do_schedule_next_timer(info); + do_schedule_next_timer(&signal->info);
even this part is not safe.
Also. The patch uses __sigqueue_free() to free the delivered siginfo, but this is not safe without ->siglock, we can race with sigqueue_free().
Oleg.
|  |