From: Greg Kroah-Hartman Date: Mon, 13 May 2013 22:08:05 +0000 (-0400) Subject: 3.0-stable patches X-Git-Tag: v3.0.79~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=65290d8dcf5e7df1959cf5efb4d1c90feef6c808;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: scsi-sd-fix-array-cache-flushing-bug-causing-performance-problems.patch xen-vcpu-pvhvm-fix-vcpu-hotplugging-hanging.patch --- diff --git a/queue-3.0/scsi-sd-fix-array-cache-flushing-bug-causing-performance-problems.patch b/queue-3.0/scsi-sd-fix-array-cache-flushing-bug-causing-performance-problems.patch new file mode 100644 index 00000000000..f1e39f64655 --- /dev/null +++ b/queue-3.0/scsi-sd-fix-array-cache-flushing-bug-causing-performance-problems.patch @@ -0,0 +1,102 @@ +From 39c60a0948cc06139e2fbfe084f83cb7e7deae3b Mon Sep 17 00:00:00 2001 +From: James Bottomley +Date: Wed, 24 Apr 2013 14:02:53 -0700 +Subject: SCSI: sd: fix array cache flushing bug causing performance problems + +From: James Bottomley + +commit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b upstream. + +Some arrays synchronize their full non volatile cache when the sd driver sends +a SYNCHRONIZE CACHE command. Unfortunately, they can have Terrabytes of this +and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a +writeback cache. This leads to massive slowdowns on journalled filesystems. + +The fix is to allow userspace to turn off the writeback cache setting as a +temporary measure (i.e. without doing the MODE SELECT to write it back to the +device), so even though the device reported it has a writeback cache, the +user, knowing that the cache is non volatile and all they care about is +filesystem correctness, can turn that bit off in the kernel and avoid the +performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands. + +The way you do this is add a 'temporary' prefix when performing the usual +cache setting operations, so + +echo temporary write through > /sys/class/scsi_disk//cache_type + +Reported-by: Ric Wheeler +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/sd.c | 20 ++++++++++++++++++++ + drivers/scsi/sd.h | 1 + + 2 files changed, 21 insertions(+) + +--- a/drivers/scsi/sd.c ++++ b/drivers/scsi/sd.c +@@ -138,6 +138,7 @@ sd_store_cache_type(struct device *dev, + char *buffer_data; + struct scsi_mode_data data; + struct scsi_sense_hdr sshdr; ++ const char *temp = "temporary "; + int len; + + if (sdp->type != TYPE_DISK) +@@ -146,6 +147,13 @@ sd_store_cache_type(struct device *dev, + * it's not worth the risk */ + return -EINVAL; + ++ if (strncmp(buf, temp, sizeof(temp) - 1) == 0) { ++ buf += sizeof(temp) - 1; ++ sdkp->cache_override = 1; ++ } else { ++ sdkp->cache_override = 0; ++ } ++ + for (i = 0; i < ARRAY_SIZE(sd_cache_types); i++) { + len = strlen(sd_cache_types[i]); + if (strncmp(sd_cache_types[i], buf, len) == 0 && +@@ -158,6 +166,13 @@ sd_store_cache_type(struct device *dev, + return -EINVAL; + rcd = ct & 0x01 ? 1 : 0; + wce = ct & 0x02 ? 1 : 0; ++ ++ if (sdkp->cache_override) { ++ sdkp->WCE = wce; ++ sdkp->RCD = rcd; ++ return count; ++ } ++ + if (scsi_mode_sense(sdp, 0x08, 8, buffer, sizeof(buffer), SD_TIMEOUT, + SD_MAX_RETRIES, &data, NULL)) + return -EINVAL; +@@ -2036,6 +2051,10 @@ sd_read_cache_type(struct scsi_disk *sdk + int old_rcd = sdkp->RCD; + int old_dpofua = sdkp->DPOFUA; + ++ ++ if (sdkp->cache_override) ++ return; ++ + first_len = 4; + if (sdp->skip_ms_page_8) { + if (sdp->type == TYPE_RBC) +@@ -2517,6 +2536,7 @@ static void sd_probe_async(void *data, a + sdkp->capacity = 0; + sdkp->media_present = 1; + sdkp->write_prot = 0; ++ sdkp->cache_override = 0; + sdkp->WCE = 0; + sdkp->RCD = 0; + sdkp->ATO = 0; +--- a/drivers/scsi/sd.h ++++ b/drivers/scsi/sd.h +@@ -70,6 +70,7 @@ struct scsi_disk { + u8 protection_type;/* Data Integrity Field */ + u8 provisioning_mode; + unsigned ATO : 1; /* state of disk ATO bit */ ++ unsigned cache_override : 1; /* temp override of WCE,RCD */ + unsigned WCE : 1; /* state of disk WCE bit */ + unsigned RCD : 1; /* state of disk RCD bit, unused */ + unsigned DPOFUA : 1; /* state of disk DPOFUA bit */ diff --git a/queue-3.0/series b/queue-3.0/series index 793cf296eaa..5dc89dc80de 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -3,3 +3,5 @@ arm-omap-rx-51-change-probe-order-of-touchscreen-and-panel-spi-devices.patch asoc-wm8994-missing-break-in-wm8994_aif3_hw_params.patch acpica-fix-possible-buffer-overflow-during-a-field-unit-read-operation.patch dm-snapshot-fix-error-return-code-in-snapshot_ctr.patch +xen-vcpu-pvhvm-fix-vcpu-hotplugging-hanging.patch +scsi-sd-fix-array-cache-flushing-bug-causing-performance-problems.patch diff --git a/queue-3.0/xen-vcpu-pvhvm-fix-vcpu-hotplugging-hanging.patch b/queue-3.0/xen-vcpu-pvhvm-fix-vcpu-hotplugging-hanging.patch new file mode 100644 index 00000000000..6f05e3615c7 --- /dev/null +++ b/queue-3.0/xen-vcpu-pvhvm-fix-vcpu-hotplugging-hanging.patch @@ -0,0 +1,108 @@ +From 7f1fc268c47491fd5e63548f6415fc8604e13003 Mon Sep 17 00:00:00 2001 +From: Konrad Rzeszutek Wilk +Date: Sun, 5 May 2013 09:30:09 -0400 +Subject: xen/vcpu/pvhvm: Fix vcpu hotplugging hanging. + +From: Konrad Rzeszutek Wilk + +commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream. + +If a user did: + + echo 0 > /sys/devices/system/cpu/cpu1/online + echo 1 > /sys/devices/system/cpu/cpu1/online + +we would (this a build with DEBUG enabled) get to: +smpboot: ++++++++++++++++++++=_---CPU UP 1 +.. snip.. +smpboot: Stack at about ffff880074c0ff44 +smpboot: CPU1: has booted. + +and hang. The RCU mechanism would kick in an try to IPI the CPU1 +but the IPIs (and all other interrupts) would never arrive at the +CPU1. At first glance at least. A bit digging in the hypervisor +trace shows that (using xenanalyze): + +[vla] d4v1 vec 243 injecting + 0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 +] 0.043163639 --|x d4v1 vmentry cycles 1468 +] 0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 + 0.043164913 --|x d4v1 inj_virq vec 243 real + [vla] d4v1 vec 243 injecting + 0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 +] 0.043165526 --|x d4v1 vmentry cycles 1472 +] 0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 + 0.043166800 --|x d4v1 inj_virq vec 243 real + [vla] d4v1 vec 243 injecting + +there is a pending event (subsequent debugging shows it is the IPI +from the VCPU0 when smpboot.c on VCPU1 has done +"set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is +interrupted with the callback IPI (0xf3 aka 243) which ends up calling +__xen_evtchn_do_upcall. + +The __xen_evtchn_do_upcall seems to do *something* but not acknowledge +the pending events. And the moment the guest does a 'cli' (that is the +ffffffff81673254 in the log above) the hypervisor is invoked again to +inject the IPI (0xf3) to tell the guest it has pending interrupts. +This repeats itself forever. + +The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup +we set each per_cpu(xen_vcpu, cpu) to point to the +shared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info +to register per-CPU structures (xen_vcpu_setup). +This is used to allow events for more than 32 VCPUs and for performance +optimizations reasons. + +When the user performs the VCPU hotplug we end up calling the +the xen_vcpu_setup once more. We make the hypercall which returns +-EINVAL as it does not allow multiple registration calls (and +already has re-assigned where the events are being set). We pick +the fallback case and set per_cpu(xen_vcpu, cpu) to point to the +shared_info->vcpu_info[vcpu] (which is a good fallback during bootup). +However the hypervisor is still setting events in the register +per-cpu structure (per_cpu(xen_vcpu_info, cpu)). + +As such when the events are set by the hypervisor (such as timer one), +and when we iterate in __xen_evtchn_do_upcall we end up reading stale +events from the shared_info->vcpu_info[vcpu] instead of the +per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the +events that the hypervisor has set and the hypervisor keeps on reminding +us to ack the events which we never do. + +The fix is simple. Don't on the second time when xen_vcpu_setup is +called over-write the per_cpu(xen_vcpu, cpu) if it points to +per_cpu(xen_vcpu_info). + +Acked-by: Stefano Stabellini +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/enlighten.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/arch/x86/xen/enlighten.c ++++ b/arch/x86/xen/enlighten.c +@@ -129,6 +129,21 @@ static void xen_vcpu_setup(int cpu) + + BUG_ON(HYPERVISOR_shared_info == &xen_dummy_shared_info); + ++ /* ++ * This path is called twice on PVHVM - first during bootup via ++ * smp_init -> xen_hvm_cpu_notify, and then if the VCPU is being ++ * hotplugged: cpu_up -> xen_hvm_cpu_notify. ++ * As we can only do the VCPUOP_register_vcpu_info once lets ++ * not over-write its result. ++ * ++ * For PV it is called during restore (xen_vcpu_restore) and bootup ++ * (xen_setup_vcpu_info_placement). The hotplug mechanism does not ++ * use this function. ++ */ ++ if (xen_hvm_domain()) { ++ if (per_cpu(xen_vcpu, cpu) == &per_cpu(xen_vcpu_info, cpu)) ++ return; ++ } + if (cpu < MAX_VIRT_CPUS) + per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu]; +