From: Greg Kroah-Hartman Date: Tue, 26 Jan 2010 19:12:56 +0000 (-0800) Subject: more .32 patches X-Git-Tag: v2.6.32.7~10 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2dde6726b4d146e380f02440a1af8a316cc81b6c;p=thirdparty%2Fkernel%2Fstable-queue.git more .32 patches --- diff --git a/queue-2.6.32/ipoib-clear-ipoib_neigh.dgid-in-ipoib_neigh_alloc.patch b/queue-2.6.32/ipoib-clear-ipoib_neigh.dgid-in-ipoib_neigh_alloc.patch new file mode 100644 index 00000000000..5e735412074 --- /dev/null +++ b/queue-2.6.32/ipoib-clear-ipoib_neigh.dgid-in-ipoib_neigh_alloc.patch @@ -0,0 +1,74 @@ +From 0cd4d0fd9b0a4e10c091fc6316d1bf92885dcd9c Mon Sep 17 00:00:00 2001 +From: David J. Wilder +Date: Wed, 9 Dec 2009 10:03:00 -0800 +Subject: IPoIB: Clear ipoib_neigh.dgid in ipoib_neigh_alloc() + +From: David J. Wilder + +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 +Signed-off-by: Roland Dreier +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-2.6.32/series b/queue-2.6.32/series index 003535dfbd1..a4e60667159 100644 --- a/queue-2.6.32/series +++ b/queue-2.6.32/series @@ -92,3 +92,5 @@ kvm-x86-fix-probable-memory-leak-of-vcpu-arch.mce_banks.patch kvm-x86-fix-leak-of-free-lapic-date-in-kvm_arch_vcpu_init.patch kvm-fix-lock-imbalance-in-kvm_-_irq_source_id.patch kvm-only-clear-irq_source_id-if-irqchip-is-present.patch +ipoib-clear-ipoib_neigh.dgid-in-ipoib_neigh_alloc.patch +x86-reenable-tsc-sync-check-at-boot-even-with-nonstop_tsc.patch diff --git a/queue-2.6.32/x86-reenable-tsc-sync-check-at-boot-even-with-nonstop_tsc.patch b/queue-2.6.32/x86-reenable-tsc-sync-check-at-boot-even-with-nonstop_tsc.patch new file mode 100644 index 00000000000..28559b24ae2 --- /dev/null +++ b/queue-2.6.32/x86-reenable-tsc-sync-check-at-boot-even-with-nonstop_tsc.patch @@ -0,0 +1,54 @@ +From 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7 Mon Sep 17 00:00:00 2001 +From: Pallipadi, Venkatesh +Date: Thu, 17 Dec 2009 12:27:02 -0800 +Subject: x86: Reenable TSC sync check at boot, even with NONSTOP_TSC + +From: Pallipadi, Venkatesh + +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 +Acked-by: Suresh Siddha +LKML-Reference: <20091217202702.GA18015@linux-os.sc.intel.com> +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + 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)