lkml.org 
[lkml]   [2010]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT] Sparc
    On Wed, Sep 22, 2010 at 12:08:53PM -0700, Linus Torvalds wrote:
    > On Wed, Sep 22, 2010 at 11:53 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
    > >
    > > Um, no. ?You've *already* called get_signal_to_deliver(). ?There had been
    > > no SIGSEGV in sight. ?You happily went on to set a sigframe for e.g.
    > > SIGHUP, but ran out of stack. ?At that point you get force_sigsegv()
    > > from handle_signal(). ?_NOW_ you have a pending SIGSEGV
    >
    > Ahh. Ok. Different case from the one I thought you were worried about.
    > And yeah, I guess that one does require us to mess with the low-level
    > asm code (although I do wonder if we could not make the whole
    > do_notify_resume + reschedule code be generic C code - it's a lot of
    > duplicated subtle asm as it is).

    BTW, there's an interesting idea in s390 implementation (and I have to say
    that I'm bloody impressed by them - it's the only architecture besides x86
    where I haven't found serious holes in signal handling yet; there are QOI
    issues, but that's it so far). What they do with syscall restarts is unusual
    and they might have a good point there.

    1) They deal with restart immediately on the entry to do_signal(); if
    restarts are not suppressed and if the error is one of the restart-worthy
    ones, they do what should be done for no-handler case.

    2) They store the pre-restart address, post-restart address and error. Then
    they call get_signal_to_deliver(). Of course, it may return us a positive
    signal number. In that case they may need to discard the restart they'd
    done. And they do it, but only if the address has remained equal to
    post-restart one.

    3) They ignore ERESTART_RESTARTBLOCK if the address has changed. Actually,
    I suspect that they might need to clear the ->restart_block.fn in that case,
    but I haven't done analysis of that yet.

    They do have a reason for doing it that way and it's worth considering on
    other platforms. Think what happens if we are getting traced. We'll be
    stopped and tracer will be notified. Normally it'll tell us to continue
    execution, possibly with a different signal *AND* with a different userland
    address to return to. Suppose we've got a different return address set
    for us (e.g. with PTRACE_POKEUSR). Should we ever shift it back by what
    hopefully is a size of syscall insn?


    \
     
     \ /
      Last update: 2010-09-23 07:01    [W:3.003 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site