From: Greg Kroah-Hartman Date: Fri, 21 Jun 2013 21:29:33 +0000 (-0700) Subject: 3.9-stable patches X-Git-Tag: v3.0.84~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=622dc6ef1a0e16aa638822a1df0a717d3628a969;p=thirdparty%2Fkernel%2Fstable-queue.git 3.9-stable patches added patches: drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch range-do-not-add-new-blank-slot-with-add_range_with_merge.patch x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch x86-fix-section-mismatch-on-load_ucode_ap.patch x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch --- diff --git a/queue-3.9/drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch b/queue-3.9/drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch new file mode 100644 index 00000000000..e285e4185bc --- /dev/null +++ b/queue-3.9/drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch @@ -0,0 +1,32 @@ +From ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 Mon Sep 17 00:00:00 2001 +From: Laurent Pinchart +Date: Wed, 19 Jun 2013 03:14:20 +0200 +Subject: drm/prime: Honor requested file flags when exporting a buffer + +From: Laurent Pinchart + +commit ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 upstream. + +The DRM PRIME API passes file flags to the driver for the exported +buffer. Honor them instead of hardcoding 0600. + +Signed-off-by: Laurent Pinchart +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_prime.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/drm_prime.c ++++ b/drivers/gpu/drm/drm_prime.c +@@ -190,8 +190,7 @@ struct dma_buf *drm_gem_prime_export(str + if (ret) + return ERR_PTR(ret); + } +- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, +- 0600); ++ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags); + } + EXPORT_SYMBOL(drm_gem_prime_export); + diff --git a/queue-3.9/drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch b/queue-3.9/drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch new file mode 100644 index 00000000000..0c67785ace4 --- /dev/null +++ b/queue-3.9/drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch @@ -0,0 +1,43 @@ +From 3813f5ca9ab7a00e80a17aab34f155453c66c78a Mon Sep 17 00:00:00 2001 +From: Jerome Glisse +Date: Thu, 6 Jun 2013 12:41:17 -0400 +Subject: drm/radeon: do not try to uselessly update virtual memory pagetable + +From: Jerome Glisse + +commit 3813f5ca9ab7a00e80a17aab34f155453c66c78a upstream. + +If a buffer is never bound to a virtual memory pagetable than don't try +to unbind it. Only drawback is that we don't update the pagetable when +unbinding the ib pool buffer which is fine because it only happens at +suspend or module unload/shutdown. + +Fixes spurious messages about buffers without VM mappings. E.g.: +radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900 + +Signed-off-by: Jerome Glisse +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_gart.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/radeon/radeon_gart.c ++++ b/drivers/gpu/drm/radeon/radeon_gart.c +@@ -1197,11 +1197,13 @@ int radeon_vm_bo_update_pte(struct radeo + int radeon_vm_bo_rmv(struct radeon_device *rdev, + struct radeon_bo_va *bo_va) + { +- int r; ++ int r = 0; + + mutex_lock(&rdev->vm_manager.lock); + mutex_lock(&bo_va->vm->mutex); +- r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL); ++ if (bo_va->soffset) { ++ r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL); ++ } + mutex_unlock(&rdev->vm_manager.lock); + list_del(&bo_va->vm_list); + mutex_unlock(&bo_va->vm->mutex); diff --git a/queue-3.9/drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch b/queue-3.9/drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch new file mode 100644 index 00000000000..eabb41d1337 --- /dev/null +++ b/queue-3.9/drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch @@ -0,0 +1,39 @@ +From 8444d5c69549aa0f0b574cc608742d4669e1cc01 Mon Sep 17 00:00:00 2001 +From: Jerome Glisse +Date: Wed, 19 Jun 2013 10:02:28 -0400 +Subject: drm/radeon: update lockup tracking when scheduling in empty ring + +From: Jerome Glisse + +commit 8444d5c69549aa0f0b574cc608742d4669e1cc01 upstream. + +There might be issue with lockup detection when scheduling on an +empty ring that have been sitting idle for a while. Thus update +the lockup tracking data when scheduling new work in an empty ring. + +Signed-off-by: Jerome Glisse +Tested-by: Andy Lutomirski +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_ring.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/gpu/drm/radeon/radeon_ring.c ++++ b/drivers/gpu/drm/radeon/radeon_ring.c +@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_devi + return -ENOMEM; + /* Align requested size with padding so unlock_commit can + * pad safely */ ++ radeon_ring_free_size(rdev, ring); ++ if (ring->ring_free_dw == (ring->ring_size / 4)) { ++ /* This is an empty ring update lockup info to avoid ++ * false positive. ++ */ ++ radeon_ring_lockup_update(ring); ++ } + ndw = (ndw + ring->align_mask) & ~ring->align_mask; + while (ndw > (ring->ring_free_dw - 1)) { + radeon_ring_free_size(rdev, ring); diff --git a/queue-3.9/range-do-not-add-new-blank-slot-with-add_range_with_merge.patch b/queue-3.9/range-do-not-add-new-blank-slot-with-add_range_with_merge.patch new file mode 100644 index 00000000000..c37a97710b9 --- /dev/null +++ b/queue-3.9/range-do-not-add-new-blank-slot-with-add_range_with_merge.patch @@ -0,0 +1,83 @@ +From 0541881502a1276149889fe468662ff6a8fc8f6d Mon Sep 17 00:00:00 2001 +From: Yinghai Lu +Date: Thu, 13 Jun 2013 13:17:02 -0700 +Subject: range: Do not add new blank slot with add_range_with_merge + +From: Yinghai Lu + +commit 0541881502a1276149889fe468662ff6a8fc8f6d upstream. + +Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge +during add range) broke mtrr cleanup on his setup in 3.9.5. +corresponding commit in upstream is fbe06b7bae7c. + +The reason is add_range_with_merge could generate blank spot. + +We could avoid that by searching new expanded start/end, that +new range should include all connected ranges in range array. +At last add the new expanded start/end to the range array. +Also move up left array so do not add new blank slot in the +range array. + +-v2: move left array to avoid enhance add_range() +-v3: include fix from Joshua about memmove declaring when + DYN_DEBUG is used. + +Reported-by: Joshua Covington +Tested-by: Joshua Covington +Signed-off-by: Yinghai Lu +Link: http://lkml.kernel.org/r/1371154622-8929-3-git-send-email-yinghai@kernel.org +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/range.c | 23 ++++++++++++----------- + 1 file changed, 12 insertions(+), 11 deletions(-) + +--- a/kernel/range.c ++++ b/kernel/range.c +@@ -4,7 +4,7 @@ + #include + #include + #include +- ++#include + #include + + int add_range(struct range *range, int az, int nr_range, u64 start, u64 end) +@@ -32,9 +32,8 @@ int add_range_with_merge(struct range *r + if (start >= end) + return nr_range; + +- /* Try to merge it with old one: */ ++ /* get new start/end: */ + for (i = 0; i < nr_range; i++) { +- u64 final_start, final_end; + u64 common_start, common_end; + + if (!range[i].end) +@@ -45,14 +44,16 @@ int add_range_with_merge(struct range *r + if (common_start > common_end) + continue; + +- final_start = min(range[i].start, start); +- final_end = max(range[i].end, end); +- +- /* clear it and add it back for further merge */ +- range[i].start = 0; +- range[i].end = 0; +- return add_range_with_merge(range, az, nr_range, +- final_start, final_end); ++ /* new start/end, will add it back at last */ ++ start = min(range[i].start, start); ++ end = max(range[i].end, end); ++ ++ memmove(&range[i], &range[i + 1], ++ (nr_range - (i + 1)) * sizeof(range[i])); ++ range[nr_range - 1].start = 0; ++ range[nr_range - 1].end = 0; ++ nr_range--; ++ i--; + } + + /* Need to add it: */ diff --git a/queue-3.9/series b/queue-3.9/series index d5638108643..a92e54311b3 100644 --- a/queue-3.9/series +++ b/queue-3.9/series @@ -33,3 +33,10 @@ kvm-x86-remove-vcpu-s-cpl-check-in-host-invoked-xcr-set.patch acpi-resources-call-acpi_get_override_irq-only-for-legacy-irq-resources.patch acpi-dock-take-acpi-scan-lock-in-write_undock.patch acpi-pm-fix-error-code-path-for-power-resources.patch +drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch +drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch +drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch +range-do-not-add-new-blank-slot-with-add_range_with_merge.patch +x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch +x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch +x86-fix-section-mismatch-on-load_ucode_ap.patch diff --git a/queue-3.9/x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch b/queue-3.9/x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch new file mode 100644 index 00000000000..28473e5bbf6 --- /dev/null +++ b/queue-3.9/x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch @@ -0,0 +1,41 @@ +From d1603990ea626668c78527376d9ec084d634202d Mon Sep 17 00:00:00 2001 +From: Randy Dunlap +Date: Tue, 18 Jun 2013 12:33:40 -0700 +Subject: x86: fix build error and kconfig for ia32_emulation and binfmt + +From: Randy Dunlap + +commit d1603990ea626668c78527376d9ec084d634202d upstream. + +Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF +when COMPAT_BINFMT_ELF is being selected. + +warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF) + +fs/built-in.o: In function `elf_core_dump': +compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs' +compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size' +compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs' +compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data' + +[ hpa: This was sent to me for -next but it is a low risk build fix ] + +Signed-off-by: Randy Dunlap +Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -2268,6 +2268,7 @@ source "fs/Kconfig.binfmt" + config IA32_EMULATION + bool "IA32 Emulation" + depends on X86_64 ++ select BINFMT_ELF + select COMPAT_BINFMT_ELF + select HAVE_UID16 + ---help--- diff --git a/queue-3.9/x86-fix-section-mismatch-on-load_ucode_ap.patch b/queue-3.9/x86-fix-section-mismatch-on-load_ucode_ap.patch new file mode 100644 index 00000000000..6483ea45935 --- /dev/null +++ b/queue-3.9/x86-fix-section-mismatch-on-load_ucode_ap.patch @@ -0,0 +1,65 @@ +From 949785996ec2250fa958fc3a924e5186e9a8fa2c Mon Sep 17 00:00:00 2001 +From: Paul Gortmaker +Date: Wed, 19 Jun 2013 11:15:26 -0400 +Subject: x86: Fix section mismatch on load_ucode_ap + +From: Paul Gortmaker + +commit 949785996ec2250fa958fc3a924e5186e9a8fa2c upstream. + +We are in the process of removing all the __cpuinit annotations. +While working on making that change, an existing problem was +made evident: + + WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch + in reference from the function cpu_init() to the function + .init.text:load_ucode_ap() The function cpu_init() references + the function __init load_ucode_ap(). This is often because cpu_init + lacks a __init annotation or the annotation of load_ucode_ap is wrong. + +This now appears because in my working tree, cpu_init() is no longer +tagged as __cpuinit, and so the audit picks up the mismatch. The 2nd +hypothesis from the audit is the correct one, as there was an incorrect +__init tag on the prototype in the header (but __cpuinit was used on +the function itself.) + +The audit is telling us that the prototype's __init annotation took +effect and the function did land in the .init.text section. Checking +with objdump on a mainline tree that still has __cpuinit shows that +the __cpuinit on the function takes precedence over the __init on the +prototype, but that won't be true once we make __cpuinit a no-op. + +Even though we are removing __cpuinit, we temporarily align both +the function and the prototype on __cpuinit so that the changeset +can be applied to stable trees if desired. + +[ hpa: build fix only, no object code change ] + +Signed-off-by: Paul Gortmaker +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: "H. Peter Anvin" +Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/microcode.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/include/asm/microcode.h ++++ b/arch/x86/include/asm/microcode.h +@@ -60,11 +60,11 @@ static inline void __exit exit_amd_micro + #ifdef CONFIG_MICROCODE_EARLY + #define MAX_UCODE_COUNT 128 + extern void __init load_ucode_bsp(void); +-extern __init void load_ucode_ap(void); ++extern void __cpuinit load_ucode_ap(void); + extern int __init save_microcode_in_initrd(void); + #else + static inline void __init load_ucode_bsp(void) {} +-static inline __init void load_ucode_ap(void) {} ++static inline void __cpuinit load_ucode_ap(void) {} + static inline int __init save_microcode_in_initrd(void) + { + return 0; diff --git a/queue-3.9/x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch b/queue-3.9/x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch new file mode 100644 index 00000000000..55a3eaa8992 --- /dev/null +++ b/queue-3.9/x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch @@ -0,0 +1,67 @@ +From d8d386c10630d8f7837700f4c466443d49e12cc0 Mon Sep 17 00:00:00 2001 +From: Yinghai Lu +Date: Thu, 13 Jun 2013 13:17:01 -0700 +Subject: x86, mtrr: Fix original mtrr range get for mtrr_cleanup + +From: Yinghai Lu + +commit d8d386c10630d8f7837700f4c466443d49e12cc0 upstream. + +Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge +during add range) broke mtrr cleanup on his setup in 3.9.5. +corresponding commit in upstream is fbe06b7bae7c. + + *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G + +https://bugzilla.kernel.org/show_bug.cgi?id=59491 + +So it rejects new var mtrr layout. + +It turns out we have some problem with initial mtrr range retrieval. +The current sequence is: + x86_get_mtrr_mem_range + ==> bunchs of add_range_with_merge + ==> bunchs of subract_range + ==> clean_sort_range + add_range_with_merge for [0,1M) + sort_range() + +add_range_with_merge could have blank slots, so we can not just +sort only, that will have final result have extra blank slot in head. + +So move that calling add_range_with_merge for [0,1M), with that we +could avoid extra clean_sort_range calling. + +Reported-by: Joshua Covington +Tested-by: Joshua Covington +Signed-off-by: Yinghai Lu +Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/mtrr/cleanup.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/x86/kernel/cpu/mtrr/cleanup.c ++++ b/arch/x86/kernel/cpu/mtrr/cleanup.c +@@ -714,15 +714,15 @@ int __init mtrr_cleanup(unsigned address + if (mtrr_tom2) + x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base; + +- nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size); + /* + * [0, 1M) should always be covered by var mtrr with WB + * and fixed mtrrs should take effect before var mtrr for it: + */ +- nr_range = add_range_with_merge(range, RANGE_NUM, nr_range, 0, ++ nr_range = add_range_with_merge(range, RANGE_NUM, 0, 0, + 1ULL<<(20 - PAGE_SHIFT)); +- /* Sort the ranges: */ +- sort_range(range, nr_range); ++ /* add from var mtrr at last */ ++ nr_range = x86_get_mtrr_mem_range(range, nr_range, ++ x_remove_base, x_remove_size); + + range_sums = sum_ranges(range, nr_range); + printk(KERN_INFO "total RAM covered: %ldM\n",