--- /dev/null
+From 0cd4d0fd9b0a4e10c091fc6316d1bf92885dcd9c Mon Sep 17 00:00:00 2001
+From: David J. Wilder <dwilder@us.ibm.com>
+Date: Wed, 9 Dec 2009 10:03:00 -0800
+Subject: IPoIB: Clear ipoib_neigh.dgid in ipoib_neigh_alloc()
+
+From: David J. Wilder <dwilder@us.ibm.com>
+
+commit 0cd4d0fd9b0a4e10c091fc6316d1bf92885dcd9c upstream.
+
+IPoIB can miss a change in destination GID under some conditions. The
+problem is caused when ipoib_neigh->dgid contains a stale address.
+The fix is to set ipoib_neigh->dgid to zero in ipoib_neigh_alloc().
+
+This can happen when a system using bonding on its IPoIB interfaces
+has switched its active interface from interface A to B and back to A.
+The system that fails over will not correctly processes the 2nd
+address change, as described below.
+
+When an address has changed neighbor->ha is updated with the new
+address. Each neighbor has an associated ipoib_neigh.
+ipoib_neigh->dgid also holds a copy of the remote node's hardware
+address. When an address changes neighbor->ha is updated by the
+network layer (arp code) with the new address. IPoIB detects this
+change in ipoib_start_xmit() by comparing neighbor->ha with
+ipoib_neigh->dgid. The bug is that ipoib_neigh->dgid may already
+contain the new address (A) thus the change from B to A is missed by
+ipoib. Here is the sequence of events:
+
+ ipoib_neigh->dgid = A and neighbor->ha = A
+
+The address is switched to B (the first switch)
+
+ neighbor->ha = B
+
+The change is seen in ipoib_start_xmit() -- neighbor->ha !=
+ipoib_neigh->dgid so ipoib_neigh is released, and a new one is
+allocated.
+
+The allocator may return the same chunk of memory that was just
+released, therefore ipoib_neigh->dgid still contains A at this point.
+
+ipoib_neigh->dgid should be updated in neigh_add_path(), but if the
+following conditions are true dgid is not updated:
+
+ 1) __path_find() returns a path
+ 2) path->ah is NULL
+
+The remote system now switches from address B to A, neighbor->ha is
+updated to A.
+
+Now we have again : ipoib_neigh->dgid = A and neighbor->ha = A
+
+Since the addresses are the same ipoib won't process the change in
+address. Fix this by zeroing out the dgid field when allocating a new
+struct ipoib_neigh.
+
+Signed-off-by: David Wilder <dwilder@us.ibm.com>
+Signed-off-by: Roland Dreier <rolandd@cisco.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/infiniband/ulp/ipoib/ipoib_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
+@@ -884,6 +884,7 @@ struct ipoib_neigh *ipoib_neigh_alloc(st
+
+ neigh->neighbour = neighbour;
+ neigh->dev = dev;
++ memset(&neigh->dgid.raw, 0, sizeof (union ib_gid));
+ *to_ipoib_neigh(neighbour) = neigh;
+ skb_queue_head_init(&neigh->queue);
+ ipoib_cm_set(neigh, NULL);
--- /dev/null
+From 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7 Mon Sep 17 00:00:00 2001
+From: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
+Date: Thu, 17 Dec 2009 12:27:02 -0800
+Subject: x86: Reenable TSC sync check at boot, even with NONSTOP_TSC
+
+From: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
+
+commit 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7 upstream.
+
+Commit 83ce4009 did the following change
+If the TSC is constant and non-stop, also set it reliable.
+
+But, there seems to be few systems that will end up with TSC warp across
+sockets, depending on how the cpus come out of reset. Skipping TSC sync
+test on such systems may result in time inconsistency later.
+
+So, reenable TSC sync test even on constant and non-stop TSC systems.
+Set, sched_clock_stable to 1 by default and reset it in
+mark_tsc_unstable, if TSC sync fails.
+
+This change still gives perf benefit mentioned in 83ce4009 for systems
+where TSC is reliable.
+
+Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
+Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
+LKML-Reference: <20091217202702.GA18015@linux-os.sc.intel.com>
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/cpu/intel.c | 1 -
+ arch/x86/kernel/tsc.c | 1 +
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/intel.c
++++ b/arch/x86/kernel/cpu/intel.c
+@@ -70,7 +70,6 @@ static void __cpuinit early_init_intel(s
+ if (c->x86_power & (1 << 8)) {
+ set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
+ set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
+- set_cpu_cap(c, X86_FEATURE_TSC_RELIABLE);
+ sched_clock_stable = 1;
+ }
+
+--- a/arch/x86/kernel/tsc.c
++++ b/arch/x86/kernel/tsc.c
+@@ -763,6 +763,7 @@ void mark_tsc_unstable(char *reason)
+ {
+ if (!tsc_unstable) {
+ tsc_unstable = 1;
++ sched_clock_stable = 0;
+ printk(KERN_INFO "Marking TSC unstable due to %s\n", reason);
+ /* Change only the rating, when not registered */
+ if (clocksource_tsc.mult)
projects / thirdparty / kernel / stable-queue.git / commitdiff
