lkml.org 
[lkml]   [2021]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from_user()
    On Mon, Aug 30, 2021 at 2:07 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
    >
    > Incidentally, why do we bother with negation in those? Why not have
    > user_insn(), XSTATE_OP() and kernel_insn_err() return 0 or trap number...

    I really wish we didn't have that odd _ASM_EXTABLE_FAULT/
    ex_handler_fault() special case at all.

    It's *very* confusing, and it actually seems to be mis-used. It looks
    like the "copy_mc_fragile" code uses it by mistake, and doesn't
    actually want that "modify %%rax" behavior of that exception handler
    AT ALL.

    If I read that code correctly, it almost by mistake doesn't actually
    care, and will overwrite %%rax with the right result, but it doesn't
    look like the "fault code in %eax" was ever *intentional*. There's no
    mention of it.

    Maybe I'm misreading that code, but I look at it and just go "Whaa?"

    The code in user_insn() clearly *does* use that fault number (and, as
    you say, inverts it for some reason), but I wonder how much it really
    cares? Could we get rid of it, and just set a fixed error code?

    I only checked one user, but that one didn't actually care which fault
    it was, it only cared about fault-vs-no-fault.

    Linus

    Linus

    \
     
     \ /
      Last update: 2021-08-30 23:28    [W:4.234 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site