.38 patches

6 files changed, 319 insertions, 0 deletions

diff --git a/queue-2.6.38/don-t-lock-guardpage-if-the-stack-is-growing-up.patch b/queue-2.6.38/don-t-lock-guardpage-if-the-stack-is-growing-up.patch
new file mode 100644
index 0000000000..8111fcd32c
--- /dev/null
+++ b/queue-2.6.38/don-t-lock-guardpage-if-the-stack-is-growing-up.patch
@@ -0,0 +1,141 @@
+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)
diff --git a/queue-2.6.38/drm-i915-dp-be-paranoid-in-case-we-disable-a-dp-before-it-is-attached.patch b/queue-2.6.38/drm-i915-dp-be-paranoid-in-case-we-disable-a-dp-before-it-is-attached.patch
new file mode 100644
index 0000000000..adb20cb738
--- /dev/null
+++ b/queue-2.6.38/drm-i915-dp-be-paranoid-in-case-we-disable-a-dp-before-it-is-attached.patch
@@ -0,0 +1,60 @@
+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);
diff --git a/queue-2.6.38/drm-i915-lvds-only-act-on-lid-notify-when-the-device-is-on.patch b/queue-2.6.38/drm-i915-lvds-only-act-on-lid-notify-when-the-device-is-on.patch
new file mode 100644
index 0000000000..c423b58a02
--- /dev/null
+++ b/queue-2.6.38/drm-i915-lvds-only-act-on-lid-notify-when-the-device-is-on.patch
@@ -0,0 +1,37 @@
+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.
diff --git a/queue-2.6.38/drm-i915-release-object-along-create-user-fb-error-path.patch b/queue-2.6.38/drm-i915-release-object-along-create-user-fb-error-path.patch
new file mode 100644
index 0000000000..83137f3043
--- /dev/null
+++ b/queue-2.6.38/drm-i915-release-object-along-create-user-fb-error-path.patch
@@ -0,0 +1,32 @@
+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) {
diff --git a/queue-2.6.38/series b/queue-2.6.38/series
index 263dcd98d4..5fd83e0a49 100644
--- a/queue-2.6.38/series
+++ b/queue-2.6.38/series
@@ -11,3 +11,8 @@ ptrace-prepare-to-fix-racy-accesses-on-task-breakpoints.patch
 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
diff --git a/queue-2.6.38/vm-fix-vm_pgoff-wrap-in-upward-expansion.patch b/queue-2.6.38/vm-fix-vm_pgoff-wrap-in-upward-expansion.patch
new file mode 100644
index 0000000000..b0a830c1e5
--- /dev/null
+++ b/queue-2.6.38/vm-fix-vm_pgoff-wrap-in-upward-expansion.patch
@@ -0,0 +1,44 @@
+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);