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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>
Cc: Matt Helsley <matthltc@xxxxxxxxxx>
Cc: Avi Kivity <avi@xxxxxxxxxx>
commit c324b5fa45cada6be69061187fdcca93f84a87dd
Author: Oren Laadan <orenl@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Reviewed-by: Matt Helsley <matthltc@xxxxxxxxxx>
Acked-by: Serge Hallyn <serue@xxxxxxxxxx>
-----------------------------------------------------------------------
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
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
