--- /dev/null
+From 2514bc510d0c3aadcc5204056bb440fa36845147 Mon Sep 17 00:00:00 2001
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Thu, 21 Jun 2012 15:13:50 -0700
+Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs
+
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+
+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 <jbarnes@virtuousgeek.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Jonathan Nieder <jrnieder@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 Mon Sep 17 00:00:00 2001
+From: Christoph Bumiller <e0425955@student.tuwien.ac.at>
+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 <e0425955@student.tuwien.ac.at>
+
+commit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream.
+
+Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From fb6ccff667712c46b4501b920ea73a326e49626a Mon Sep 17 00:00:00 2001
+From: Zach Brown <zab@redhat.com>
+Date: Tue, 24 Jul 2012 12:10:11 -0700
+Subject: fuse: verify all ioctl retry iov elements
+
+From: Zach Brown <zab@redhat.com>
+
+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 <zab@redhat.com>
+Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 5bc6f9888db5739abfa0cae279b4b442e4db8049 Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+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 <konrad.wilk@oracle.com>
+
+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:[<ffffffff818aad3b>]
+(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 <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
