[Xen-changelog] [xen-unstable] [XEN] Work around timeout bug in old Linux kernels where

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User kaf24@xxxxxxxxxxxxxxxxxxxx
# Node ID 7d3df6492d7013f1d6c28c7aeea9743ba10649be
# Parent  2e5f6c68da5cf9d80b83141601f5e15a9fb92a1b
[XEN] Work around timeout bug in old Linux kernels where
timeout would erroneously be set far out in the future.
Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>
---
 xen/common/schedule.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+)

diff -r 2e5f6c68da5c -r 7d3df6492d70 xen/common/schedule.c
--- a/xen/common/schedule.c     Thu Jun 29 11:31:10 2006 +0100
+++ b/xen/common/schedule.c     Thu Jun 29 14:22:56 2006 +0100
@@ -391,9 +391,30 @@ long do_set_timer_op(s_time_t timeout)
     struct vcpu *v = current;
 
     if ( timeout == 0 )
+    {
         stop_timer(&v->timer);
+    }
     else
+    {
+        if ( unlikely(timeout < 0) ||
+             unlikely((uint32_t)((timeout - NOW()) >> 50) != 0) )
+        {
+            /*
+             * Linux workaround: occasionally we will see timeouts a long way
+             * in the future due to wrapping in Linux's jiffy time handling.
+             * We check for tiemouts wrapped negative, and for positive
+             * timeouts more than about 13 days in the future (2^50ns).
+             * The correct fix is to trigger an interrupt in a short while
+             * (since Linux in fact has pending work to do in this situation).
+             */
+            DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
+                    " %"PRIx64"\n",
+                    v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
+            timeout = NOW() + MILLISECS(10);
+        }
+
         set_timer(&v->timer, timeout);
+    }
 
     return 0;
 }

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog