From: Greg Kroah-Hartman Date: Thu, 16 Aug 2012 23:22:06 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.5.3~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1196dd5cb15c6d4cf0b91a3de879797fe044805b;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-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-mark-local-pages-as-foreign-in-the-m2p_override.patch xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch --- diff --git a/queue-3.4/drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch b/queue-3.4/drm-i915-prefer-wide-slow-to-fast-narrow-in-dp-configs.patch new file mode 100644 index 00000000000..d645f5a0f1a --- /dev/null +++ b/queue-3.4/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 +@@ -712,8 +712,8 @@ intel_dp_mode_fixup(struct drm_encoder * + + bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24; + +- 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 (intel_dp_link_required(mode->clock, bpp) diff --git a/queue-3.4/drm-nvd0-disp-mask-off-high-16-bit-of-negative-cursor-x-coordinate.patch b/queue-3.4/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.4/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.4/fuse-verify-all-ioctl-retry-iov-elements.patch b/queue-3.4/fuse-verify-all-ioctl-retry-iov-elements.patch new file mode 100644 index 00000000000..5376929055e --- /dev/null +++ b/queue-3.4/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 +@@ -1698,7 +1698,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.4/series b/queue-3.4/series index b624e35c32c..43328a57293 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -1,3 +1,8 @@ s390-compat-fix-compat-wrappers-for-process_vm-system-calls.patch s390-compat-fix-mmap-compat-system-calls.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 +xen-mark-local-pages-as-foreign-in-the-m2p_override.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.4/xen-mark-local-pages-as-foreign-in-the-m2p_override.patch b/queue-3.4/xen-mark-local-pages-as-foreign-in-the-m2p_override.patch new file mode 100644 index 00000000000..caaf876a43a --- /dev/null +++ b/queue-3.4/xen-mark-local-pages-as-foreign-in-the-m2p_override.patch @@ -0,0 +1,154 @@ +From b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +Date: Wed, 23 May 2012 18:57:20 +0100 +Subject: xen: mark local pages as FOREIGN in the m2p_override + +From: Stefano Stabellini + +commit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream. + +When the frontend and the backend reside on the same domain, even if we +add pages to the m2p_override, these pages will never be returned by +mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will +always fail, so the pfn of the frontend will be returned instead +(resulting in a deadlock because the frontend pages are already locked). + +INFO: task qemu-system-i38:1085 blocked for more than 120 seconds. +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +qemu-system-i38 D ffff8800cfc137c0 0 1085 1 0x00000000 + ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0 + ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0 + ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0 +Call Trace: + [] ? __lock_page+0x70/0x70 + [] schedule+0x29/0x70 + [] io_schedule+0x60/0x80 + [] sleep_on_page+0xe/0x20 + [] __wait_on_bit_lock+0x5a/0xc0 + [] __lock_page+0x67/0x70 + [] ? autoremove_wake_function+0x40/0x40 + [] ? bio_add_page+0x36/0x40 + [] set_page_dirty_lock+0x52/0x60 + [] bio_set_pages_dirty+0x51/0x70 + [] do_blockdev_direct_IO+0xb24/0xeb0 + [] ? ext3_get_blocks_handle+0xe00/0xe00 + [] __blockdev_direct_IO+0x55/0x60 + [] ? ext3_get_blocks_handle+0xe00/0xe00 + [] ext3_direct_IO+0xf8/0x390 + [] ? ext3_get_blocks_handle+0xe00/0xe00 + [] ? xen_mc_flush+0xb0/0x1b0 + [] generic_file_aio_read+0x737/0x780 + [] ? gnttab_map_refs+0x15b/0x1e0 + [] ? find_get_pages+0x150/0x150 + [] aio_rw_vect_retry+0x7c/0x1d0 + [] ? lookup_ioctx+0x90/0x90 + [] aio_run_iocb+0x66/0x1a0 + [] do_io_submit+0x708/0xb90 + [] sys_io_submit+0x10/0x20 + [] system_call_fastpath+0x16/0x1b + +The explanation is in the comment within the code: + +We need to do this because the pages shared by the frontend +(xen-blkfront) can be already locked (lock_page, called by +do_read_cache_page); when the userspace backend tries to use them +with direct_IO, mfn_to_pfn returns the pfn of the frontend, so +do_blockdev_direct_IO is going to try to lock the same pages +again resulting in a deadlock. + +A simplified call graph looks like this: + +pygrub QEMU +----------------------------------------------- +do_read_cache_page io_submit + | | +lock_page ext3_direct_IO + | + bio_add_page + | + lock_page + +Internally the xen-blkback uses m2p_add_override to swizzle (temporarily) +a 'struct page' to have a different MFN (so that it can point to another +guest). It also can easily find out whether another pfn corresponding +to the mfn exists in the m2p, and can set the FOREIGN bit +in the p2m, making sure that mfn_to_pfn returns the pfn of the backend. + +This allows the backend to perform direct_IO on these pages, but as a +side effect prevents the frontend from using get_user_pages_fast on +them while they are being shared with the backend. + +Signed-off-by: Stefano Stabellini +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/p2m.c | 36 ++++++++++++++++++++++++++++++++++++ + 1 file changed, 36 insertions(+) + +--- a/arch/x86/xen/p2m.c ++++ b/arch/x86/xen/p2m.c +@@ -691,6 +691,7 @@ int m2p_add_override(unsigned long mfn, + unsigned long uninitialized_var(address); + unsigned level; + pte_t *ptep = NULL; ++ int ret = 0; + + pfn = page_to_pfn(page); + if (!PageHighMem(page)) { +@@ -726,6 +727,24 @@ int m2p_add_override(unsigned long mfn, + list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); + spin_unlock_irqrestore(&m2p_override_lock, flags); + ++ /* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in ++ * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other ++ * pfn so that the following mfn_to_pfn(mfn) calls will return the ++ * pfn from the m2p_override (the backend pfn) instead. ++ * We need to do this because the pages shared by the frontend ++ * (xen-blkfront) can be already locked (lock_page, called by ++ * do_read_cache_page); when the userspace backend tries to use them ++ * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so ++ * do_blockdev_direct_IO is going to try to lock the same pages ++ * again resulting in a deadlock. ++ * As a side effect get_user_pages_fast might not be safe on the ++ * frontend pages while they are being shared with the backend, ++ * because mfn_to_pfn (that ends up being called by GUPF) will ++ * return the backend pfn rather than the frontend pfn. */ ++ ret = __get_user(pfn, &machine_to_phys_mapping[mfn]); ++ if (ret == 0 && get_phys_to_machine(pfn) == mfn) ++ set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)); ++ + return 0; + } + EXPORT_SYMBOL_GPL(m2p_add_override); +@@ -737,6 +756,7 @@ int m2p_remove_override(struct page *pag + unsigned long uninitialized_var(address); + unsigned level; + pte_t *ptep = NULL; ++ int ret = 0; + + pfn = page_to_pfn(page); + mfn = get_phys_to_machine(pfn); +@@ -806,6 +826,22 @@ int m2p_remove_override(struct page *pag + } else + set_phys_to_machine(pfn, page->index); + ++ /* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present ++ * somewhere in this domain, even before being added to the ++ * m2p_override (see comment above in m2p_add_override). ++ * If there are no other entries in the m2p_override corresponding ++ * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for ++ * the original pfn (the one shared by the frontend): the backend ++ * cannot do any IO on this page anymore because it has been ++ * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of ++ * the original pfn causes mfn_to_pfn(mfn) to return the frontend ++ * pfn again. */ ++ mfn &= ~FOREIGN_FRAME_BIT; ++ ret = __get_user(pfn, &machine_to_phys_mapping[mfn]); ++ if (ret == 0 && get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) && ++ m2p_find_override(mfn) == NULL) ++ set_phys_to_machine(pfn, mfn); ++ + return 0; + } + EXPORT_SYMBOL_GPL(m2p_remove_override); diff --git a/queue-3.4/xen-p2m-reserve-8mb-of-_brk-space-for-p2m-leafs-when-populating-back.patch b/queue-3.4/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.4/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);