--- /dev/null
+From a09a79f66874c905af35d5bb5e5f2fdc7b6b894d Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+Date: Mon, 9 May 2011 13:01:09 +0200
+Subject: Don't lock guardpage if the stack is growing up
+
+From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+
+commit a09a79f66874c905af35d5bb5e5f2fdc7b6b894d upstream.
+
+Linux kernel excludes guard page when performing mlock on a VMA with
+down-growing stack. However, some architectures have up-growing stack
+and locking the guard page should be excluded in this case too.
+
+This patch fixes lvm2 on PA-RISC (and possibly other architectures with
+up-growing stack). lvm2 calculates number of used pages when locking and
+when unlocking and reports an internal error if the numbers mismatch.
+
+[ Patch changed fairly extensively to also fix /proc/<pid>/maps for the
+ grows-up case, and to move things around a bit to clean it all up and
+ share the infrstructure with the /proc bits.
+
+ Tested on ia64 that has both grow-up and grow-down segments - Linus ]
+
+Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+Tested-by: Tony Luck <tony.luck@gmail.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/proc/task_mmu.c | 12 +++++++-----
+ include/linux/mm.h | 24 +++++++++++++++++++++++-
+ mm/memory.c | 16 +++++++---------
+ 3 files changed, 37 insertions(+), 15 deletions(-)
+
+--- a/fs/proc/task_mmu.c
++++ b/fs/proc/task_mmu.c
+@@ -211,7 +211,7 @@ static void show_map_vma(struct seq_file
+ int flags = vma->vm_flags;
+ unsigned long ino = 0;
+ unsigned long long pgoff = 0;
+- unsigned long start;
++ unsigned long start, end;
+ dev_t dev = 0;
+ int len;
+
+@@ -224,13 +224,15 @@ static void show_map_vma(struct seq_file
+
+ /* We don't show the stack guard page in /proc/maps */
+ start = vma->vm_start;
+- if (vma->vm_flags & VM_GROWSDOWN)
+- if (!vma_stack_continue(vma->vm_prev, vma->vm_start))
+- start += PAGE_SIZE;
++ if (stack_guard_page_start(vma, start))
++ start += PAGE_SIZE;
++ end = vma->vm_end;
++ if (stack_guard_page_end(vma, end))
++ end -= PAGE_SIZE;
+
+ seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu %n",
+ start,
+- vma->vm_end,
++ end,
+ flags & VM_READ ? 'r' : '-',
+ flags & VM_WRITE ? 'w' : '-',
+ flags & VM_EXEC ? 'x' : '-',
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -994,11 +994,33 @@ int set_page_dirty_lock(struct page *pag
+ int clear_page_dirty_for_io(struct page *page);
+
+ /* Is the vma a continuation of the stack vma above it? */
+-static inline int vma_stack_continue(struct vm_area_struct *vma, unsigned long addr)
++static inline int vma_growsdown(struct vm_area_struct *vma, unsigned long addr)
+ {
+ return vma && (vma->vm_end == addr) && (vma->vm_flags & VM_GROWSDOWN);
+ }
+
++static inline int stack_guard_page_start(struct vm_area_struct *vma,
++ unsigned long addr)
++{
++ return (vma->vm_flags & VM_GROWSDOWN) &&
++ (vma->vm_start == addr) &&
++ !vma_growsdown(vma->vm_prev, addr);
++}
++
++/* Is the vma a continuation of the stack vma below it? */
++static inline int vma_growsup(struct vm_area_struct *vma, unsigned long addr)
++{
++ return vma && (vma->vm_start == addr) && (vma->vm_flags & VM_GROWSUP);
++}
++
++static inline int stack_guard_page_end(struct vm_area_struct *vma,
++ unsigned long addr)
++{
++ return (vma->vm_flags & VM_GROWSUP) &&
++ (vma->vm_end == addr) &&
++ !vma_growsup(vma->vm_next, addr);
++}
++
+ extern unsigned long move_page_tables(struct vm_area_struct *vma,
+ unsigned long old_addr, struct vm_area_struct *new_vma,
+ unsigned long new_addr, unsigned long len);
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -1412,9 +1412,8 @@ no_page_table:
+
+ static inline int stack_guard_page(struct vm_area_struct *vma, unsigned long addr)
+ {
+- return (vma->vm_flags & VM_GROWSDOWN) &&
+- (vma->vm_start == addr) &&
+- !vma_stack_continue(vma->vm_prev, addr);
++ return stack_guard_page_start(vma, addr) ||
++ stack_guard_page_end(vma, addr+PAGE_SIZE);
+ }
+
+ int __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
+@@ -1502,12 +1501,6 @@ int __get_user_pages(struct task_struct
+ continue;
+ }
+
+- /*
+- * For mlock, just skip the stack guard page.
+- */
+- if ((gup_flags & FOLL_MLOCK) && stack_guard_page(vma, start))
+- goto next_page;
+-
+ do {
+ struct page *page;
+ unsigned int foll_flags = gup_flags;
+@@ -1524,6 +1517,11 @@ int __get_user_pages(struct task_struct
+ int ret;
+ unsigned int fault_flags = 0;
+
++ /* For mlock, just skip the stack guard page. */
++ if (foll_flags & FOLL_MLOCK) {
++ if (stack_guard_page(vma, start))
++ goto next_page;
++ }
+ if (foll_flags & FOLL_WRITE)
+ fault_flags |= FAULT_FLAG_WRITE;
+ if (nonblocking)
--- /dev/null
+From 31acbcc408f412d1ba73765b846c38642be553c3 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sun, 17 Apr 2011 06:38:35 +0100
+Subject: drm/i915/dp: Be paranoid in case we disable a DP before it is attached
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 31acbcc408f412d1ba73765b846c38642be553c3 upstream.
+
+Given that the hardware may be left in a random condition by the BIOS,
+it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
+without us ever enabling/attaching the DP encoder to a pipe. Thus
+causing a NULL deference when we attempt to wait for a vblank on that
+crtc.
+
+Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
+Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_dp.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -1455,7 +1455,8 @@ intel_dp_link_down(struct intel_dp *inte
+
+ if (!HAS_PCH_CPT(dev) &&
+ I915_READ(intel_dp->output_reg) & DP_PIPEB_SELECT) {
+- struct intel_crtc *intel_crtc = to_intel_crtc(intel_dp->base.base.crtc);
++ struct drm_crtc *crtc = intel_dp->base.base.crtc;
++
+ /* Hardware workaround: leaving our transcoder select
+ * set to transcoder B while it's off will prevent the
+ * corresponding HDMI output on transcoder A.
+@@ -1470,7 +1471,19 @@ intel_dp_link_down(struct intel_dp *inte
+ /* Changes to enable or select take place the vblank
+ * after being written.
+ */
+- intel_wait_for_vblank(dev, intel_crtc->pipe);
++ if (crtc == NULL) {
++ /* We can arrive here never having been attached
++ * to a CRTC, for instance, due to inheriting
++ * random state from the BIOS.
++ *
++ * If the pipe is not running, play safe and
++ * wait for the clocks to stabilise before
++ * continuing.
++ */
++ POSTING_READ(intel_dp->output_reg);
++ msleep(50);
++ } else
++ intel_wait_for_vblank(dev, to_intel_crtc(crtc)->pipe);
+ }
+
+ I915_WRITE(intel_dp->output_reg, DP & ~DP_PORT_EN);
--- /dev/null
+From 2fb4e61d9471867677c97bf11dba8f1e9dfa7f7c Mon Sep 17 00:00:00 2001
+From: Alex Williamson <alex.williamson@redhat.com>
+Date: Thu, 21 Apr 2011 16:08:14 -0600
+Subject: drm/i915/lvds: Only act on lid notify when the device is on
+
+From: Alex Williamson <alex.williamson@redhat.com>
+
+commit 2fb4e61d9471867677c97bf11dba8f1e9dfa7f7c upstream.
+
+If we're using vga switcheroo, the device may be turned off
+and poking it can return random state. This provokes an OOPS fixed
+separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
+DP before it is attached). Trying to use and respond to events on a
+device that has been turned off by the user is in principle a silly thing
+to do.
+
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_lvds.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_lvds.c
++++ b/drivers/gpu/drm/i915/intel_lvds.c
+@@ -540,6 +540,9 @@ static int intel_lid_notify(struct notif
+ struct drm_device *dev = dev_priv->dev;
+ struct drm_connector *connector = dev_priv->int_lvds_connector;
+
++ if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
++ return NOTIFY_OK;
++
+ /*
+ * check and update the status of LVDS connector after receiving
+ * the LID nofication event.
--- /dev/null
+From 2dd251f0a294300a1cf8f4b63768145fa6153c4d Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sat, 16 Apr 2011 10:23:51 +0100
+Subject: drm/i915: Release object along create user fb error path
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 2dd251f0a294300a1cf8f4b63768145fa6153c4d upstream.
+
+Reported-by: Alan Cox <alan@linux.intel.com>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -6005,8 +6005,10 @@ intel_user_framebuffer_create(struct drm
+ return ERR_PTR(-ENOENT);
+
+ intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
+- if (!intel_fb)
++ if (!intel_fb) {
++ drm_gem_object_unreference_unlocked(&obj->base);
+ return ERR_PTR(-ENOMEM);
++ }
+
+ ret = intel_framebuffer_init(dev, intel_fb, mode_cmd, obj);
+ if (ret) {
hw_breakpoints-powerpc-fix-config_have_hw_breakpoint-off-case-in-ptrace_set_debugreg.patch
iwlwifi-add-ack-plpc-_check-module-parameters.patch
drm-radeon-kms-fix-gart-setup-on-fusion-parts-v2-backport.patch
+vm-fix-vm_pgoff-wrap-in-upward-expansion.patch
+don-t-lock-guardpage-if-the-stack-is-growing-up.patch
+drm-i915-dp-be-paranoid-in-case-we-disable-a-dp-before-it-is-attached.patch
+drm-i915-lvds-only-act-on-lid-notify-when-the-device-is-on.patch
+drm-i915-release-object-along-create-user-fb-error-path.patch
--- /dev/null
+From 42c36f63ac1366ab0ecc2d5717821362c259f517 Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Mon, 9 May 2011 17:44:42 -0700
+Subject: vm: fix vm_pgoff wrap in upward expansion
+
+From: Hugh Dickins <hughd@google.com>
+
+commit 42c36f63ac1366ab0ecc2d5717821362c259f517 upstream.
+
+Commit a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed
+the case of an expanding mapping causing vm_pgoff wrapping when you had
+downward stack expansion. But there was another case where IA64 and
+PA-RISC expand mappings: upward expansion.
+
+This fixes that case too.
+
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ mm/mmap.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1767,10 +1767,13 @@ int expand_upwards(struct vm_area_struct
+ size = address - vma->vm_start;
+ grow = (address - vma->vm_end) >> PAGE_SHIFT;
+
+- error = acct_stack_growth(vma, size, grow);
+- if (!error) {
+- vma->vm_end = address;
+- perf_event_mmap(vma);
++ error = -ENOMEM;
++ if (vma->vm_pgoff + (size >> PAGE_SHIFT) >= vma->vm_pgoff) {
++ error = acct_stack_growth(vma, size, grow);
++ if (!error) {
++ vma->vm_end = address;
++ perf_event_mmap(vma);
++ }
+ }
+ }
+ vma_unlock_anon_vma(vma);
projects / thirdparty / kernel / stable-queue.git / commitdiff
