• Paolo 'Blaisorblade' Giarrusso's avatar
    [PATCH] uml: clean arch_switch usage · 972410b0
    Paolo 'Blaisorblade' Giarrusso authored
    Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
    that case (and mark this in the comment); this will change soon.
    
    Also, arch_switch for TT mode is actually useless when the PT proxy (a
    complicate debugging instrumentation for TT mode) is not enabled.  In fact, it
    only calls update_debugregs, which checks debugregs_seq against seq (to check
    if the registers are up-to-date - seq here means a "version number" of the
    registers).
    
    If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
    update_debugregs will be a no-op.  So, optimize this out (the compiler can't
    do it).
    
    Also, I've been disappointed by the fact that it would make a lot of sense if,
    after calling a successful
    update_debugregs(current->thread.arch.debugregs_seq),
    current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
    But this is not done.  Is this a bug or a feature?  For all purposes, it seems
    a bug (otherwise the whole mechanism does not make sense, which is also a
    possibility to check), which causes some performance only problems (not
    correctness), since we write_debugregs when not needed.
    
    Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
    comprised in the subsequent local_irq_enable().  I'm just a bit dubious if
    ordering matters there...
    Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
    Acked-by: default avatarJeff Dike <jdike@addtoit.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    972410b0
process_kern.c 4.65 KB