On 08/24, taoyue wrote:
Oleg Nesterov wrote:
I know, using current->sighand->siglock to prevent one sigqueuecollect_signal: sigqueue_free:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
list_del_init(&first->list);
spin_lock_irqsave(lock, flags);
if (!list_empty(&q->list))collect_signal() is always called under ->siglock which is also taken by
list_del_init(&q->list);
spin_unlock_irqrestore(lock, flags);
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
sigqueue_free(), so this is not possible.
Basically, this patch is the same one-liner I sent you before
http://marc.info/?l=linux-kernel&m=118772206603453&w=2
(Thanks for the additional testing and report, btw).
P.S. It would be nice to know if this patch solves the problems reported
by Jeremy, but his email is disabled.
Oleg.
is free twice. I want to know whether it is possible that the two
function is called in different thread. If that, the spin_lock is useless.
Not sure I understand. Yes, it is possible they are called by 2 different
threads, that is why we had a race. But all threads in the same thread
group have the same ->sighand, and thus the same ->sighand->siglock.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/