[lkml]   [2007]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] sigqueue_free: fix the race with collect_signal()
On 08/27, taoyue wrote:
> Oleg Nesterov wrote:
> >On 08/24, Sukadev Bhattiprolu wrote:
> >>>>>
> >>>>I know, using current->sighand->siglock to prevent one sigqueue
> >>>>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.
> >>>
> I has applied the new patch, and start test program last Friday.
> So far, the test program has run for three days.

Great, thanks.

> In my test program, all threads is created in one process, so they
> are in the same thread group. If two thread is not in the same thread
> group, they have the different ->sighand->siglock. In this case, the
> lock can't prevent the sigqueue object from race condition.

If two thread are not in the same thread, they can't access the same
SIGQUEUE_PREALLOC sigqueue. That is why sigqueue_free() uses current->sighand.
Otherwise, this lock doesn't make any sense, and can't protect list_del(q->list).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-27 08:01    [W:0.027 / U:0.576 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site