[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.023 / U:6.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site