lkml.org 
[lkml]   [2019]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch V2 07/17] x86/entry/64: Remove redundant interrupt disable
    On Thu, Oct 24, 2019 at 10:52:59PM +0200, Thomas Gleixner wrote:
    > is just undefined behaviour and I personally consider it to be a plain bug.

    I concur.

    > Just for the record: This results in running a resulting or even completely
    > unrelated signal handler with interrupts disabled as well.
    >
    > Whatever we decide it is, leaving it completely inconsistent is not a
    > solution at all. The options are:
    >
    > 1) Always do conditional tracing depending on the user_regs->eflags.IF
    > state.
    >
    > 2) #1 + warn once when syscalls and exceptions (except NMI/MCE) happen
    > and user_regs->eflags.IF is cleared.
    >
    > 3a) #2 + enforce signal handling to run with interrupts enabled.
    >
    > 3b) #2 + set regs->eflags.IF. So the state is always correct from the
    > kernel POV. Of course that changes existing behaviour, but its
    > changing undefined and inconsistent behaviour.
    >
    > 4) Let iopl(level) return -EPERM if level == 3.
    >
    > Yeah, I know it's not possible due to regressions (DPKD uses iopl(3)),
    > but TBH that'd be the sanest option of all.
    >
    > Of course the infinite wisdom of hardware designers tied IN, INS, OUT,
    > OUTS and CLI/STI together on IOPL so we cannot even distangle them in
    > any way.
    >
    > The only way out would be to actually use a full 8K sized I/O bitmap,
    > but that's a massive pain as it has to be copied on every context
    > switch.
    >
    > Really pretty options to chose from ...

    If 4 is out (and I'm afraid it might be), then I'm on record for liking
    3b.

    \
     
     \ /
      Last update: 2019-10-24 23:22    [W:5.253 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site