[lkml]   [2011]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Likely race between sys_rt_sigtimedwait() and complete_signal()
    Can't find the original email, replying to Andrew's fwd.

    On 04/07, Andrew Morton wrote:
    > Within project we are working on, we are facing a "rare" situation when
    > setitimer() / sigwait() - based periodic task execution hangs. "Rare"
    > means once per several hours for 1000 Hz timer.
    > For hanged thread, cat /proc/pid/status shows
    > ...
    > State: S (sleeping)
    > ...
    > SigPnd: 0000000000000000
    > ShdPnd: 0000000000002000
    > SigBlk: 0000000000000000
    > ...
    > and SysRq - T shows
    > [<c015b1b0>] (__schedule+0x2fc/0x37c) from [<c015b7b8>]
    > (schedule+0x1c/0x30)
    > [<c015b7b8>] (schedule+0x1c/0x30) from [<c015b8c4>]
    > (schedule_timeout+0x18/0x1dc)
    > [<c015b8c4>] (schedule_timeout+0x18/0x1dc) from [<c004a084>]
    > (sys_rt_sigtimedwait+0x1b4/0x288)
    > [<c004a084>] (sys_rt_sigtimedwait+0x1b4/0x288) from [<c001cf00>]
    > (ret_fast_syscall+0x0/0x28)

    Is this thread the group leader?

    > All other threads have SIGALRM blocked as they should, looking
    > through /proc/X/status proves this.

    Do they ever had SIGALRM unlblocked ?

    > So for some reason, SIGALRM was successfully delivered by timer, bit was
    > set in ShdPnd [I guess at the bottom of __send_signal()], but that still
    > resulted somehow in thread going to schedule() and not waking.

    Thanks for the detailed report.

    There is an old, ancient problem which I constantly forget to fix.
    It _can_ perfectly explain the hang, at least in theory. I'll try
    to make the patch on Monday.

    In short: if a thread T runs with SIGALRM unblocked while another
    thread sleeps in sigtimedwait(), and then T blocks SIGALRM, the
    signal can be "lost" as above.

    Does your application do something like this? If not, then there
    is another problem.

    > This is on embedded system running vendor 2.6.31-based kernel, moving
    > forward is unfortunately impossible because of hardware support issues.

    If I make the patch for 2.6.31, any chance you can test it?

    > However I guess the race we faced still exists in the current upstream
    > kernel,

    Yes, this is possible. OTOH, the bug can be anywhere, not necessarily in
    signal.c, and it might be already fixed.


     \ /
      Last update: 2011-04-09 15:49    [W:0.023 / U:138.388 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site