lkml.org 
[lkml]   [2010]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Subjectsigno issues in arch/x86/kernel/traps.c
    From
    There are several  -- to me, peculiar -- signal number choices being
    made in arch/x86/kernel/traps.c. Here are my observations...

    #1. Exception 9 -- "coprocessor segment overrun" -- should not be
    forwarded, leave alone forwarded as a SIGFPE. Exception 9 is not a
    fault, but an abort-class exception. The task _must_ die. Exception 9
    occurs when a discrete coprocessor -- i.e. one that is not on the same
    die as the processor -- writes to an operand in memory that crosses a
    page boundary, _and_ one page is writeable but the other is not. So,
    under these conditions, when the coprocessor writes to mem, part of
    the write succeeds and the other part fails. Since the operand in
    memory then contains garbage, subsequent cpu and fpu instructions must
    be prevented from using it, and with the fpu confused (should its
    state be that from before or after the computation that precipitated
    the write?), the task cannot be allowed to recover from the exception.

    Incidentally: it seems that the math emulator is trying to avoid just
    that sort of partial-write-success situation with all the limits
    checking that its doing. (pm_address() in math-emu/get_address.c)
    Perhaps a uaccess function for atomic writes (either write completely
    or not at all) would be generally useful?

    #2. An exception 7 -- "device not available" -- exception should not
    result in a SIGFPE being sent to the task. An FPE can -- nomen est
    omen -- (what is it with traps.c's reticence in passing siginfo?)
    precipitate fiddling with the state of the (non-existent) fpu, which
    will naturally trip another "device not available". Since the "device
    not available" exception is just a particular kind of "cannot handle
    this opcode" event, and the appropriate signal for "cannot handle this
    opcode" events is SIGILL, exception 7 should cause a SIGILL.

    #3. Exception 12 -- named "stack segment" in traps.c -- should
    translate into a SEGV, not a SIGBUS. Exception 12 is a segment
    violation, even if it is a particular kind of segment violation. The
    "Stack-Segment Fault" is the %ss selector's equivalent of a GPF that
    occurs for an access with %cs/ds/es/fs/gs. Just as loading
    cs/es/ds/fs/gs with a bad/null selector will trip exception 13, so
    will loading ss with a bad/null selector cause an exception 12. The
    principle function of exception 12 is to automatically grow an
    expand-down stack segment when an access occurs beyond the limit
    defined in the %ss selector's descriptor. But a simple mov <bad
    address>, %ebp; mov (%ebp), %eax can trip it too since %ebp is
    implicitly based against %ss. Not functionally any different from a
    simple mov <bad address>, %ebx; mov (%ebx), %eax. I can't think of any
    reason why exception 12 should be a SIGBUS while exception 13 is a
    SEGV.

    #4. Exception 5 -- "bounds" -- should not translate to a SEGV.
    Exception 5 occurs when a programmer deliberately wants to test
    whether an integer is within a certain range, for which he/she uses
    the BOUND instruction.
    if (foo < range.lo || foo > range.hi)
    printf("hey! out of bounds\n");
    The if() is simple signed integer math comparison, not a bad memory
    access. (if there were a fault accessing range.{hi|lo}, the exception
    being raised would be a GPF, not a bounds).

    #5. Exception 4 -- "overflow" -- should probably not translate to a
    SEGV. Exception 4 ("interrupt 4"), generated by INTO, is like
    exception 3 ("interrupt 3"), generated by INT3. It too is a trap-class
    exception, and really a debug instruction. As with all trap-class
    exceptions, the task's eip is pointing to the next instruction, and a
    simple ret will seamlessly continue execution as if nothing had
    happened (unlike a real SEGV). In this sense, its probably not a good
    idea to deal with it as a SEGV. There is also no violation there,
    leave alone a segment violation. It isn't like an INT x for an
    unhandled interrupt vector. After all, the interrupt is being handled.
    I suggest treating it just like int3 is treated. i.e. SIGTRAP.

    Regards,
    Cyrus


    \
     
     \ /
      Last update: 2010-08-08 05:31    [W:0.036 / U:31.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site