lkml.org 
[lkml]   [2002]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] compatibility syscall layer (lets try again)
    On Fri, Dec 06, 2002 at 09:57:08AM -0800, Linus Torvalds wrote:
    >
    > I just pushed my version of the system call restart code to the BK trees.
    > It's losely based on Georges code, but subtly different. Also, I didn't
    > actually update any actual system calls to use it, I just did the
    > infrastructure.
    >
    > Non-x86 architectures need to be updated to work with this: they need to
    > update their thread structures, the additional do_signal() support in
    > their signal.c, and add the actual system call itself somewhere. For x86,
    > this was about 15 lines of changes.
    >
    > The basic premise is very simple: if you want to restart a system call,
    > you can do
    >
    > restart = &current_thread()->restart_block;
    > restart->fn = my_continuation_function;
    > restart->arg0 = my_arg0_for_continuation;
    > restart->arg1 = my_arg1_for_continuation;
    > ..
    > return -ERESTARTSYS_RESTARTBLOCK;
    >
    > which will cause the system call to either return -EINTR (if a signal
    > handler was actually invoced) or for "benign" signals (SIGSTOP etc) it
    > will end up restarting the system call at the continuation function (with
    > the "restart" block as the argument).
    >
    > We could extend this to allow restarting even over signal handlers, but
    > that would have some re-entrancy issues (ie what happens if a signal
    > handler itself wants to use a system call that may want restarting), so at
    > least for now restarting is only done when no handler is invoced (*).
    >
    > Linus
    >
    > (*) The nesting case is by no means impossible to handle gracefully
    > (adding a "restart even if handler is called" error number and returning
    > -EINTR if nesting, for example), but I don't know of any system calls that
    > would really want to try to restart anyway, so..

    Well, here's something to consider. This isn't entirely hypothetical;
    there are test cases in GDB's regression suite that cover nearly this.

    Suppose a process is sleeping for an hour. The user wants to see what
    another thread is doing, so he hits Control-C; the thread which happens
    to be reported as 'current' is the one that was in nanosleep(). It
    used to be that when he said continue, the nanosleep would return; now
    hopefully it'll continue. Great! But this damnable user isn't done
    yet. He wants to look at one of his data structures. He calls a
    debugging print_foo() function from GDB. He realizes he left a
    sleep-for-a-minute nanosleep call in it and C-c's again. Now we have
    two interrupted nanosleep calls and the application will never see a
    signal to interrupt either of them; he says "continue" twice and
    expects to get back to his hour-long sleep.

    Note that I'm not saying we _need_ to support this, mind :) It's a
    little pathological.

    Another thing that annoys me slightly about this is that we mess with
    the value in orig_eax etc. Now a debugger would have to look at the
    instruction stream to figure out what the syscall was that we're
    stopped in, reliably. Not a big deal.

    --
    Daniel Jacobowitz
    MontaVista Software Debian GNU/Linux Developer
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:31    [W:0.028 / U:0.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site