From: Greg Kroah-Hartman Date: Thu, 16 Aug 2012 23:22:14 +0000 (-0700) Subject: 3.5-stable patches X-Git-Tag: v3.5.3~27 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e7d078c83d322dd7c18546c2af33b21915b1e001;p=thirdparty%2Fkernel%2Fstable-queue.git 3.5-stable patches added patches: drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch fuse-verify-all-ioctl-retry-iov-elements.patch xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch --- diff --git a/queue-3.5/drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch b/queue-3.5/drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch new file mode 100644 index 00000000000..5ce1ac98fa8 --- /dev/null +++ b/queue-3.5/drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch @@ -0,0 +1,39 @@ +From 2514bc510d0c3aadcc5204056bb440fa36845147 Mon Sep 17 00:00:00 2001 +From: Jesse Barnes +Date: Thu, 21 Jun 2012 15:13:50 -0700 +Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs + +From: Jesse Barnes + +commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream. + +High frequency link configurations have the potential to cause trouble +with long and/or cheap cables, so prefer slow and wide configurations +instead. This patch has the potential to cause trouble for eDP +configurations that lie about available lanes, so if we run into that we +can make it conditional on eDP. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801 +Tested-by: peter@colberg.org +Signed-off-by: Jesse Barnes +Signed-off-by: Daniel Vetter +Cc: Jonathan Nieder +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_dp.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_dp.c ++++ b/drivers/gpu/drm/i915/intel_dp.c +@@ -726,8 +726,8 @@ intel_dp_mode_fixup(struct drm_encoder * + bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24; + mode_rate = intel_dp_link_required(mode->clock, bpp); + +- for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) { +- for (clock = 0; clock <= max_clock; clock++) { ++ for (clock = 0; clock <= max_clock; clock++) { ++ for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) { + int link_avail = intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count); + + if (mode_rate <= link_avail) { diff --git a/queue-3.5/drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch b/queue-3.5/drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch new file mode 100644 index 00000000000..17ba9933811 --- /dev/null +++ b/queue-3.5/drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch @@ -0,0 +1,28 @@ +From af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 Mon Sep 17 00:00:00 2001 +From: Christoph Bumiller +Date: Thu, 26 Jul 2012 20:53:19 +0200 +Subject: drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate + +From: Christoph Bumiller + +commit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream. + +Signed-off-by: Christoph Bumiller +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nvd0_display.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nvd0_display.c ++++ b/drivers/gpu/drm/nouveau/nvd0_display.c +@@ -790,7 +790,7 @@ nvd0_crtc_cursor_move(struct drm_crtc *c + struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); + int ch = EVO_CURS(nv_crtc->index); + +- evo_piow(crtc->dev, ch, 0x0084, (y << 16) | x); ++ evo_piow(crtc->dev, ch, 0x0084, (y << 16) | (x & 0xffff)); + evo_piow(crtc->dev, ch, 0x0080, 0x00000000); + return 0; + } diff --git a/queue-3.5/fuse-verify-all-ioctl-retry-iov-elements.patch b/queue-3.5/fuse-verify-all-ioctl-retry-iov-elements.patch new file mode 100644 index 00000000000..3e5844d3215 --- /dev/null +++ b/queue-3.5/fuse-verify-all-ioctl-retry-iov-elements.patch @@ -0,0 +1,42 @@ +From fb6ccff667712c46b4501b920ea73a326e49626a Mon Sep 17 00:00:00 2001 +From: Zach Brown +Date: Tue, 24 Jul 2012 12:10:11 -0700 +Subject: fuse: verify all ioctl retry iov elements + +From: Zach Brown + +commit fb6ccff667712c46b4501b920ea73a326e49626a upstream. + +Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that +the total iovec from the client doesn't overflow iov_length() but it +only checked the first element. The iovec could still overflow by +starting with a small element. The obvious fix is to check all the +elements. + +The overflow case doesn't look dangerous to the kernel as the copy is +limited by the length after the overflow. This fix restores the +intention of returning an error instead of successfully copying less +than the iovec represented. + +I found this by code inspection. I built it but don't have a test case. +I'm cc:ing stable because the initial commit did as well. + +Signed-off-by: Zach Brown +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/fuse/file.c ++++ b/fs/fuse/file.c +@@ -1700,7 +1700,7 @@ static int fuse_verify_ioctl_iov(struct + size_t n; + u32 max = FUSE_MAX_PAGES_PER_REQ << PAGE_SHIFT; + +- for (n = 0; n < count; n++) { ++ for (n = 0; n < count; n++, iov++) { + if (iov->iov_len > (size_t) max) + return -ENOMEM; + max -= iov->iov_len; diff --git a/queue-3.5/series b/queue-3.5/series index 4b101955aa4..ba381c02461 100644 --- a/queue-3.5/series +++ b/queue-3.5/series @@ -3,3 +3,7 @@ s390-compat-fix-mmap-compat-system-calls.patch nouveau-fixup-scanout-enable-in-nvc0_pm.patch drm-mgag200-fix-g200er-pll-picking-algorithm.patch dma-imx-dma-fix-kernel-crash-due-to-missing-clock-conversion.patch +fuse-verify-all-ioctl-retry-iov-elements.patch +xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch +drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch +drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch diff --git a/queue-3.5/xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch b/queue-3.5/xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch new file mode 100644 index 00000000000..d17d2fbace4 --- /dev/null +++ b/queue-3.5/xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch @@ -0,0 +1,82 @@ +From 5bc6f9888db5739abfa0cae279b4b442e4db8049 Mon Sep 17 00:00:00 2001 +From: Konrad Rzeszutek Wilk +Date: Mon, 30 Jul 2012 10:18:05 -0400 +Subject: xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back. + +From: Konrad Rzeszutek Wilk + +commit 5bc6f9888db5739abfa0cae279b4b442e4db8049 upstream. + +When we release pages back during bootup: + +Freeing 9d-100 pfn range: 99 pages freed +Freeing 9cf36-9d0d2 pfn range: 412 pages freed +Freeing 9f6bd-9f6bf pfn range: 2 pages freed +Freeing 9f714-9f7bf pfn range: 171 pages freed +Freeing 9f7e0-9f7ff pfn range: 31 pages freed +Freeing 9f800-100000 pfn range: 395264 pages freed +Released 395979 pages of unused memory + +We then try to populate those pages back. In the P2M tree however +the space for those leafs must be reserved - as such we use extend_brk. +We reserve 8MB of _brk space, which means we can fit over +1048576 PFNs - which is more than we should ever need. + +Without this, on certain compilation of the kernel we would hit: + +(XEN) domain_crash_sync called from entry.S +(XEN) CPU: 0 +(XEN) RIP: e033:[] +(XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest +(XEN) rax: ffffffff81a7c000 rbx: 000000000000003d rcx: 0000000000001000 +(XEN) rdx: ffffffff81a7b000 rsi: 0000000000001000 rdi: 0000000000001000 +(XEN) rbp: ffffffff81801cd8 rsp: ffffffff81801c98 r8: 0000000000100000 +(XEN) r9: ffffffff81a7a000 r10: 0000000000000001 r11: 0000000000000003 +(XEN) r12: 0000000000000004 r13: 0000000000000004 r14: 000000000000003d +(XEN) r15: 00000000000001e8 cr0: 000000008005003b cr4: 00000000000006f0 +(XEN) cr3: 0000000125803000 cr2: 0000000000000000 +(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 +(XEN) Guest stack trace from rsp=ffffffff81801c98: + +.. which is extend_brk hitting a BUG_ON. + +Interestingly enough, most of the time we are not going to hit this +b/c the _brk space is quite large (v3.5): + ffffffff81a25000 B __brk_base + ffffffff81e43000 B __brk_limit += ~4MB. + +vs earlier kernels (with this back-ported), the space is smaller: + ffffffff81a25000 B __brk_base + ffffffff81a7b000 B __brk_limit += 344 kBytes. + +where we would certainly hit this and hit extend_brk. + +Note that git commit c3d93f880197953f86ab90d9da4744e926b38e33 +(xen: populate correct number of pages when across mem boundary (v2)) +exposed this bug). + +[v1: Made it 8MB of _brk space instead of 4MB per Jan's suggestion] + +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/p2m.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/xen/p2m.c ++++ b/arch/x86/xen/p2m.c +@@ -194,6 +194,11 @@ RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MA + * boundary violation will require three middle nodes. */ + RESERVE_BRK(p2m_mid_identity, PAGE_SIZE * 2 * 3); + ++/* When we populate back during bootup, the amount of pages can vary. The ++ * max we have is seen is 395979, but that does not mean it can't be more. ++ * But some machines can have 3GB I/O holes even. So lets reserve enough ++ * for 4GB of I/O and E820 holes. */ ++RESERVE_BRK(p2m_populated, PMD_SIZE * 4); + static inline unsigned p2m_top_index(unsigned long pfn) + { + BUG_ON(pfn >= MAX_P2M_PFN);