[lkml]   [2007]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v2] fix for futex_wait signal stack corruption

    On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
    > While this was observed with process control signals, my concern was that
    > other signals might cause pthread_cond_timedwait to return immediately in the
    > same way. The test program allows for SIGUSR1 and SIGRTMIN testing as well,
    > but these other signals did not cause the immediate return. But it would seem
    > from Steven's analysis that this is just a fortuitous result. If I understand
    > things correctly, any interruption of pthread_cond_timedwait by a signal,
    > could result in waiting until an arbitrary time - depending on how the stack
    > value was corrupted. Is that correct?

    No, very few things can actually cause the restart_block path to be taken.
    An actual signal execution would turn that into an EINTR, the only case
    that should ever trigger this is a signal that causes some kernel action
    (ie the system call *is* interrupted), but does not actually result in any
    user-visible state changes.

    The classic case is ^Z + bg, but iirc you can trigger it with ptrace too.
    And I think two threads racing to pick up the same signal can cause it
    too, for that matter (ie one thread takes the signal, the other one got
    interrupted but there's nothing there, so it just causes a system call

    There's basically two different system call restart mechanisms in the

    - returning -ERESTARTNOHAND will cause the system call to be restarted
    with the *original* arguments if no signal handler was actually
    invoked. This has been around for a long time, and is used by a lot of
    system calls. It's fine for things that are idempotent, ie the argument
    meaning doesn't change over time (things like a "read()" system call,
    for example)

    - the "restart_block" model that returns -ERESTARTBLOCK, which will cause
    the system call to be restarted with the arguments specified in the
    system call restart block. This is for system calls that are *not*
    idempotent, ie the argument might be a relative timeout or something
    like that, where we need to actually behave *differently* when

    The latter case is "new" (it's been around for a while, but relative to
    the ERESTARTNOHAND one), and it relies on the system call itself setting
    up its restart point and the argument save area. And each such system call
    can obviously screw it up by saving/restoring the arguments with the
    incorrect semantics.

    So this bug was really (a) specific to that particular futex restart
    mechanism, and (b) only triggers for the (rather unusual) case where the
    system call gets interrupted by a signal, but no signal handler actually
    happens. In practice, ^Z is the most common case by far (other signals are
    either ignored and don't even cause an interrupt event in the first place,
    or they are "real" signals, and cause a signal handler to be invoked).


     \ /
      Last update: 2007-12-05 07:09    [W:0.033 / U:12.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site