[Devel] [cr][git]linux-cr branch, ckpt-v18-dev, updated. v2.6.31-126-gc1405ac

[orenl at cs.columbia.edu]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "linux-cr".

The branch, ckpt-v18-dev has been updated
       via  c1405acba1fe1450593da966a4a4c37ab049e785 (commit)
       via  c324b5fa45cada6be69061187fdcca93f84a87dd (commit)
      from  8adba1cc04ec7c406969990e2a1c0ba5c94a9d73 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit c1405acba1fe1450593da966a4a4c37ab049e785
Author: Oren Laadan <orenl at cs.columbia.edu>
Date:   Thu Oct 29 20:32:50 2009 -0400

    c/r: tolerate X86_EFLAGS_RF on restart
    
    On restart, the c/r code that sanitizes a task's EFLAGS failed with an
    error if the X86_EFLAGS_RF was set. However, there are cases in which
    a task legitimately has this flag recorded at checkpoint, such as:
    
    1) We are running inside a KVM guest, and the guest is being debugged
    (see arch/x86/kvm/{svm,vmx}.c, via callbacks from qemu.
    
    2) The kernel itself is being debugged using kgbd.
    
    3) Exceptions that occur under certain condition will set this flag
    on the currently running task. For details see page 679 in Intel's
    manual (http://www.intel.com/Assets/PDF/manual/253668.pdf), like:
    
      When calling an event handler, Intel 64 and IA-32 processors
      establish the value of the RF flag in the EFLAGS image pushed on the
      stack:
        • For any fault-class exception except a debug exception
          generated in response to an instruction breakpoint, the value
          pushed for RF is 1.
        • For any interrupt arriving after any iteration of a repeated
          string instruction but the last iteration, the value pushed for
          RF is 1.
        • For any trap-class exception generated by any iteration of a
          repeated string instruction but the last iteration, the value
          pushed for RF is 1.
        • For other cases, the value pushed for RF is the value that was
          in EFLAG.RF at the time the event handler was called.
      [...]
    
    Case #3 is consistent with the fact that in all cases where we
    observed the issue there was a sendmail process doing IO.
    
    Clearly, the X86_EFLAGS_RF is valid to be set.
    
    This patches fixes the restart to:
    
    1) Silently ignore the X86_EFLAGS_RF if was set at checkpoint: this
    allows restart to tolerate the flag and safely complete the restart.
    
    2) Preserve the existing X86_EFLAGS_RF of a restarting task (instead
    of overwriting it): this ensures that restarting does not interfere
    with kvm, kgdb, etc.
    
    Signed-off-by: Oren Laadan <orenl at cs.columbia.edu>
    Cc: Alexey Dobriyan <adobriyan at gmail.com>
    Cc: Matt Helsley <matthltc at us.ibm.com>
    Cc: Avi Kivity <avi at redhat.com>

commit c324b5fa45cada6be69061187fdcca93f84a87dd
Author: Oren Laadan <orenl at cs.columbia.edu>
Date:   Thu Oct 29 20:32:50 2009 -0400

    c/r: factor out objref handling from {_,}ckpt_read_obj()
    
    As noted by Matt Helsley, a portion of one of these functions was
    missing the block "dispatching" errors. Otherwise the handling of
    shard objects is pretty much the same, so this patch factors out the
    common code.
    
    Signed-off-by: Oren Laadan <orenl at cs.columbia.edu>
    Reviewed-by: Matt Helsley <matthltc at us.ibm.com>
    Acked-by: Serge Hallyn <serue at us.ibm.com>

-----------------------------------------------------------------------

Summary of changes:
 arch/x86/mm/checkpoint.c |   42 +++++++++++++++++++++++++++++++-
 checkpoint/restart.c     |   58 ++++++++++++++++++++++++---------------------
 2 files changed, 71 insertions(+), 29 deletions(-)


hooks/post-receive
--
linux-cr
-------------- next part --------------
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers