--- /dev/null
+From fed08d036f2aabd8d0c684439de37f8ebec2bbc2 Mon Sep 17 00:00:00 2001
+From: Jody Bruchon <jody@nctritech.com>
+Date: Sat, 6 Feb 2010 10:46:26 -0500
+Subject: ALSA: hda-intel: Avoid divide by zero crash
+
+From: Jody Bruchon <jody@nctritech.com>
+
+commit fed08d036f2aabd8d0c684439de37f8ebec2bbc2 upstream.
+
+On my AMD780V chipset, hda_intel.c can crash the kernel with a divide by
+zero
+for as-yet unknown reasons. A simple check for zero prevents it, though
+the problem that causes it remains. Since the workaround is harmless and
+won't affect anyone except victims of this bug, it should be safe;
+moreover,
+because this crash can be triggered by a user-mode application, there are
+denial of service implications on the systems affected by the bug without
+the patch.
+
+Signed-off-by: Jody Bruchon <jody@nctritech.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/hda/hda_intel.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1858,6 +1858,12 @@ static int azx_position_ok(struct azx *c
+
+ if (!bdl_pos_adj[chip->dev_index])
+ return 1; /* no delayed ack */
++ if (azx_dev->period_bytes == 0) {
++ printk(KERN_WARNING
++ "hda-intel: Divide by zero was avoided "
++ "in azx_dev->period_bytes.\n");
++ return 0;
++ }
+ if (pos % azx_dev->period_bytes > azx_dev->period_bytes / 2)
+ return 0; /* NG - it's below the period boundary */
+ return 1; /* OK, it's fine */
--- /dev/null
+From 531c2dc70d339c5dfa8c3eb628c3459dc6f3a075 Mon Sep 17 00:00:00 2001
+From: Stephen M. Cameron <scameron@beardog.cce.hp.com>
+Date: Fri, 5 Feb 2010 13:14:04 +0100
+Subject: cciss: Make cciss_seq_show handle holes in the h->drv[] array
+
+From: Stephen M. Cameron <scameron@beardog.cce.hp.com>
+
+commit 531c2dc70d339c5dfa8c3eb628c3459dc6f3a075 upstream.
+
+It is possible (and expected) for there to be holes in the h->drv[]
+array, that is, some elements may be NULL pointers. cciss_seq_show
+needs to be made aware of this possibility to avoid an Oops.
+
+To reproduce the Oops which this fixes:
+
+1) Create two "arrays" in the Array Configuratino Utility and
+ several logical drives on each array.
+2) cat /proc/driver/cciss/cciss* in an infinite loop
+3) delete some of the logical drives in the first "array."
+
+Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
+Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/block/cciss.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/block/cciss.c
++++ b/drivers/block/cciss.c
+@@ -339,6 +339,9 @@ static int cciss_seq_show(struct seq_fil
+ if (*pos > h->highest_lun)
+ return 0;
+
++ if (drv == NULL) /* it's possible for h->drv[] to have holes. */
++ return 0;
++
+ if (drv->heads == 0)
+ return 0;
+
--- /dev/null
+From f12f98dba6ea1517cd7fbb912208893b9c014c15 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Fri, 5 Feb 2010 13:14:00 -0500
+Subject: cifs: fix length calculation for converted unicode readdir names
+
+From: Jeff Layton <jlayton@redhat.com>
+
+commit f12f98dba6ea1517cd7fbb912208893b9c014c15 upstream.
+
+cifs_from_ucs2 returns the length of the converted name, including the
+length of the NULL terminator. We don't want to include the NULL
+terminator in the dentry name length however since that'll throw off the
+hash calculation for the dentry cache.
+
+I believe that this is the root cause of several problems that have
+cropped up recently that seem to be papered over with the "noserverino"
+mount option. More confirmation of that would be good, but this is
+clearly a bug and it fixes at least one reproducible problem that
+was reported.
+
+This patch fixes at least this reproducer in this kernel.org bug:
+
+ http://bugzilla.kernel.org/show_bug.cgi?id=15088#c12
+
+Reported-by: Bjorn Tore Sund <bjorn.sund@it.uib.no>
+Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/cifs/readdir.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/cifs/readdir.c
++++ b/fs/cifs/readdir.c
+@@ -666,6 +666,7 @@ static int cifs_get_name_from_search_buf
+ min(len, max_len), nlt,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
++ pqst->len -= nls_nullsize(nlt);
+ } else {
+ pqst->name = filename;
+ pqst->len = len;
--- /dev/null
+From 557a701c16553b0b691dbb64ef30361115a80f64 Mon Sep 17 00:00:00 2001
+From: Thomas Renninger <trenn@suse.de>
+Date: Mon, 14 Dec 2009 11:44:15 +0100
+Subject: CPUFREQ: Fix use after free of struct powernow_k8_data
+
+From: Thomas Renninger <trenn@suse.de>
+
+commit 557a701c16553b0b691dbb64ef30361115a80f64 upstream.
+
+Easy fix for a regression introduced in 2.6.31.
+
+On managed CPUs the cpufreq.c core will call driver->exit(cpu) on the
+managed cpus and powernow_k8 will free the core's data.
+
+Later driver->get(cpu) function might get called trying to read out the
+current freq of a managed cpu and the NULL pointer check does not work on
+the freed object -> better set it to NULL.
+
+->get() is unsigned and must return 0 as invalid frequency.
+
+Reference:
+http://bugzilla.kernel.org/show_bug.cgi?id=14391
+
+Signed-off-by: Thomas Renninger <trenn@suse.de>
+Tested-by: Michal Schmidt <mschmidt@redhat.com>
+Signed-off-by: Dave Jones <davej@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
++++ b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
+@@ -1351,6 +1351,7 @@ static int __devexit powernowk8_cpu_exit
+
+ kfree(data->powernow_table);
+ kfree(data);
++ per_cpu(powernow_data, pol->cpu) = NULL;
+
+ return 0;
+ }
+@@ -1370,7 +1371,7 @@ static unsigned int powernowk8_get(unsig
+ int err;
+
+ if (!data)
+- return -EINVAL;
++ return 0;
+
+ smp_call_function_single(cpu, query_values_on_cpu, &err, true);
+ if (err)
--- /dev/null
+From ee25df2bc379728c45d81e04cf87984db1425edf Mon Sep 17 00:00:00 2001
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Sat, 6 Feb 2010 10:41:53 -0800
+Subject: drm/i915: handle FBC and self-refresh better
+
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+
+commit ee25df2bc379728c45d81e04cf87984db1425edf upstream.
+
+On 945, we need to avoid entering self-refresh if the compressor is
+busy, or we may cause display FIFO underruns leading to ugly flicker.
+
+Fixes fdo bug #24314, kernel bug #15043.
+
+Tested-by: Alexander Lam <lambchop468@gmail.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Tested-by: Julien Cristau <jcristau@debian.org> (fd.o #25371)
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_reg.h | 1 +
+ drivers/gpu/drm/i915/intel_display.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -329,6 +329,7 @@
+ #define FBC_CTL_PERIODIC (1<<30)
+ #define FBC_CTL_INTERVAL_SHIFT (16)
+ #define FBC_CTL_UNCOMPRESSIBLE (1<<14)
++#define FBC_C3_IDLE (1<<13)
+ #define FBC_CTL_STRIDE_SHIFT (5)
+ #define FBC_CTL_FENCENO (1<<0)
+ #define FBC_COMMAND 0x0320c
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -988,6 +988,8 @@ static void i8xx_enable_fbc(struct drm_c
+
+ /* enable it... */
+ fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
++ if (IS_I945GM(dev))
++ fbc_ctl |= FBC_C3_IDLE; /* 945 needs special SR handling */
+ fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
+ fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
+ if (obj_priv->tiling_mode != I915_TILING_NONE)
--- /dev/null
+From fd2e8ea597222b8f38ae8948776a61ea7958232e Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 9 Feb 2010 14:14:36 +0000
+Subject: drm/i915: Increase fb alignment to 64k
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit fd2e8ea597222b8f38ae8948776a61ea7958232e upstream.
+
+An untiled framebuffer must be aligned to 64k. This is normally handled
+by intel_pin_and_fence_fb_obj(), but the intelfb_create() likes to be
+different and do the pinning itself. However, it aligns the buffer
+object incorrectly for pre-i965 chipsets causing a PGTBL_ERR when it is
+installed onto the output.
+
+Fixes:
+ KMS error message while initializing modesetting -
+ render error detected: EIR: 0x10 [i915]
+ http://bugs.freedesktop.org/show_bug.cgi?id=22936
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_fb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_fb.c
++++ b/drivers/gpu/drm/i915/intel_fb.c
+@@ -148,7 +148,7 @@ static int intelfb_create(struct drm_dev
+
+ mutex_lock(&dev->struct_mutex);
+
+- ret = i915_gem_object_pin(fbo, PAGE_SIZE);
++ ret = i915_gem_object_pin(fbo, 64*1024);
+ if (ret) {
+ DRM_ERROR("failed to pin fb: %d\n", ret);
+ goto out_unref;
--- /dev/null
+From 99fcb766a3a50466fe31d743260a3400c1aee855 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sun, 7 Feb 2010 16:20:18 +0100
+Subject: drm/i915: Update write_domains on active list after flush.
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 99fcb766a3a50466fe31d743260a3400c1aee855 upstream.
+
+Before changing the status of a buffer with a pending write we will await
+upon a new flush for that buffer. So we can take advantage of any flushes
+posted whilst the buffer is active and pending processing by the GPU, by
+clearing its write_domain and updating its last_rendering_seqno -- thus
+saving a potential flush in deep queues and improves flushing behaviour
+upon eviction for both GTT space and fences.
+
+In order to reduce the time spent searching the active list for matching
+write_domains, we move those to a separate list whose elements are
+the buffers belong to the active/flushing list with pending writes.
+
+Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported
+by me.
+
+In addition to better performance, this also fixes a real bug. Before
+this changes, i915_gem_evict_everything didn't work as advertised. When
+the gpu was actually busy and processing request, the flush and subsequent
+wait would not move active and dirty buffers to the inactive list, but
+just to the flushing list. Which triggered the BUG_ON at the end of this
+function. With the more tight dirty buffer tracking, all currently busy and
+dirty buffers get moved to the inactive list by one i915_gem_flush operation.
+
+I've left the BUG_ON I've used to prove this in there.
+
+References:
+ Bug 25911 - 2.10.0 causes kernel oops and system hangs
+ http://bugs.freedesktop.org/show_bug.cgi?id=25911
+
+ Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops
+ within seconds after login
+ http://bugs.freedesktop.org/show_bug.cgi?id=26101
+
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Tested-by: Adam Lantos <hege@playma.org>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_drv.h | 11 +++++++++++
+ drivers/gpu/drm/i915/i915_gem.c | 23 +++++++++++++++++++----
+ 2 files changed, 30 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -467,6 +467,15 @@ typedef struct drm_i915_private {
+ struct list_head flushing_list;
+
+ /**
++ * List of objects currently pending a GPU write flush.
++ *
++ * All elements on this list will belong to either the
++ * active_list or flushing_list, last_rendering_seqno can
++ * be used to differentiate between the two elements.
++ */
++ struct list_head gpu_write_list;
++
++ /**
+ * LRU list of objects which are not in the ringbuffer and
+ * are ready to unbind, but are still in the GTT.
+ *
+@@ -558,6 +567,8 @@ struct drm_i915_gem_object {
+
+ /** This object's place on the active/flushing/inactive lists */
+ struct list_head list;
++ /** This object's place on GPU write list */
++ struct list_head gpu_write_list;
+
+ /** This object's place on the fenced object LRU */
+ struct list_head fence_list;
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -1552,6 +1552,8 @@ i915_gem_object_move_to_inactive(struct
+ else
+ list_move_tail(&obj_priv->list, &dev_priv->mm.inactive_list);
+
++ BUG_ON(!list_empty(&obj_priv->gpu_write_list));
++
+ obj_priv->last_rendering_seqno = 0;
+ if (obj_priv->active) {
+ obj_priv->active = 0;
+@@ -1622,7 +1624,8 @@ i915_add_request(struct drm_device *dev,
+ struct drm_i915_gem_object *obj_priv, *next;
+
+ list_for_each_entry_safe(obj_priv, next,
+- &dev_priv->mm.flushing_list, list) {
++ &dev_priv->mm.gpu_write_list,
++ gpu_write_list) {
+ struct drm_gem_object *obj = obj_priv->obj;
+
+ if ((obj->write_domain & flush_domains) ==
+@@ -1630,6 +1633,7 @@ i915_add_request(struct drm_device *dev,
+ uint32_t old_write_domain = obj->write_domain;
+
+ obj->write_domain = 0;
++ list_del_init(&obj_priv->gpu_write_list);
+ i915_gem_object_move_to_active(obj, seqno);
+
+ trace_i915_gem_object_change_domain(obj,
+@@ -2073,8 +2077,8 @@ static int
+ i915_gem_evict_everything(struct drm_device *dev)
+ {
+ drm_i915_private_t *dev_priv = dev->dev_private;
+- uint32_t seqno;
+ int ret;
++ uint32_t seqno;
+ bool lists_empty;
+
+ spin_lock(&dev_priv->mm.active_list_lock);
+@@ -2096,6 +2100,8 @@ i915_gem_evict_everything(struct drm_dev
+ if (ret)
+ return ret;
+
++ BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
++
+ ret = i915_gem_evict_from_inactive_list(dev);
+ if (ret)
+ return ret;
+@@ -2690,7 +2696,7 @@ i915_gem_object_flush_gpu_write_domain(s
+ old_write_domain = obj->write_domain;
+ i915_gem_flush(dev, 0, obj->write_domain);
+ seqno = i915_add_request(dev, NULL, obj->write_domain);
+- obj->write_domain = 0;
++ BUG_ON(obj->write_domain);
+ i915_gem_object_move_to_active(obj, seqno);
+
+ trace_i915_gem_object_change_domain(obj,
+@@ -3710,16 +3716,23 @@ i915_gem_execbuffer(struct drm_device *d
+ i915_gem_flush(dev,
+ dev->invalidate_domains,
+ dev->flush_domains);
+- if (dev->flush_domains)
++ if (dev->flush_domains & I915_GEM_GPU_DOMAINS)
+ (void)i915_add_request(dev, file_priv,
+ dev->flush_domains);
+ }
+
+ for (i = 0; i < args->buffer_count; i++) {
+ struct drm_gem_object *obj = object_list[i];
++ struct drm_i915_gem_object *obj_priv = obj->driver_private;
+ uint32_t old_write_domain = obj->write_domain;
+
+ obj->write_domain = obj->pending_write_domain;
++ if (obj->write_domain)
++ list_move_tail(&obj_priv->gpu_write_list,
++ &dev_priv->mm.gpu_write_list);
++ else
++ list_del_init(&obj_priv->gpu_write_list);
++
+ trace_i915_gem_object_change_domain(obj,
+ obj->read_domains,
+ old_write_domain);
+@@ -4112,6 +4125,7 @@ int i915_gem_init_object(struct drm_gem_
+ obj_priv->obj = obj;
+ obj_priv->fence_reg = I915_FENCE_REG_NONE;
+ INIT_LIST_HEAD(&obj_priv->list);
++ INIT_LIST_HEAD(&obj_priv->gpu_write_list);
+ INIT_LIST_HEAD(&obj_priv->fence_list);
+ obj_priv->madv = I915_MADV_WILLNEED;
+
+@@ -4563,6 +4577,7 @@ i915_gem_load(struct drm_device *dev)
+ spin_lock_init(&dev_priv->mm.active_list_lock);
+ INIT_LIST_HEAD(&dev_priv->mm.active_list);
+ INIT_LIST_HEAD(&dev_priv->mm.flushing_list);
++ INIT_LIST_HEAD(&dev_priv->mm.gpu_write_list);
+ INIT_LIST_HEAD(&dev_priv->mm.inactive_list);
+ INIT_LIST_HEAD(&dev_priv->mm.request_list);
+ INIT_LIST_HEAD(&dev_priv->mm.fence_list);
--- /dev/null
+From 4b06e5b9ad8abb20105b2b25e42c509ebe9b2d76 Mon Sep 17 00:00:00 2001
+From: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+Date: Fri, 29 Jan 2010 09:56:22 +0900
+Subject: freeze_bdev: don't deactivate successfully frozen MS_RDONLY sb
+
+From: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+
+commit 4b06e5b9ad8abb20105b2b25e42c509ebe9b2d76 upstream.
+
+Thanks Thomas and Christoph for testing and review.
+I removed 'smp_wmb()' before up_write from the previous patch,
+since up_write() should have necessary ordering constraints.
+(I.e. the change of s_frozen is visible to others after up_write)
+I'm quite sure the change is harmless but if you are uncomfortable
+with Tested-by/Reviewed-by on the modified patch, please remove them.
+
+If MS_RDONLY, freeze_bdev should just up_write(s_umount) instead of
+deactivate_locked_super().
+Also, keep sb->s_frozen consistent so that remount can check the frozen state.
+
+Otherwise a crash reported here can happen:
+http://lkml.org/lkml/2010/1/16/37
+http://lkml.org/lkml/2010/1/28/53
+
+This patch should be applied for 2.6.32 stable series, too.
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Tested-by: Thomas Backlund <tmb@mandriva.org>
+Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+--- a/fs/block_dev.c
++++ b/fs/block_dev.c
+@@ -246,7 +246,8 @@ struct super_block *freeze_bdev(struct block_device *bdev)
+ if (!sb)
+ goto out;
+ if (sb->s_flags & MS_RDONLY) {
+- deactivate_locked_super(sb);
++ sb->s_frozen = SB_FREEZE_TRANS;
++ up_write(&sb->s_umount);
+ mutex_unlock(&bdev->bd_fsfreeze_mutex);
+ return sb;
+ }
+@@ -307,7 +308,7 @@ int thaw_bdev(struct block_device *bdev, struct super_block *sb)
+ BUG_ON(sb->s_bdev != bdev);
+ down_write(&sb->s_umount);
+ if (sb->s_flags & MS_RDONLY)
+- goto out_deactivate;
++ goto out_unfrozen;
+
+ if (sb->s_op->unfreeze_fs) {
+ error = sb->s_op->unfreeze_fs(sb);
+@@ -321,11 +322,11 @@ int thaw_bdev(struct block_device *bdev, struct super_block *sb)
+ }
+ }
+
++out_unfrozen:
+ sb->s_frozen = SB_UNFROZEN;
+ smp_wmb();
+ wake_up(&sb->s_wait_unfrozen);
+
+-out_deactivate:
+ if (sb)
+ deactivate_locked_super(sb);
+ out_unlock:
--- /dev/null
+From 803bf5ec259941936262d10ecc84511b76a20921 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Wed, 10 Feb 2010 13:56:42 -0800
+Subject: fs/exec.c: restrict initial stack space expansion to rlimit
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit 803bf5ec259941936262d10ecc84511b76a20921 upstream.
+
+When reserving stack space for a new process, make sure we're not
+attempting to expand the stack by more than rlimit allows.
+
+This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
+variable length argument support") and unmasked by
+fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails
+to return errors").
+
+This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
+80K on 4K pages or 'ulimit -s 79') all processes will be killed before
+they start. This is particularly bad with 64K pages, where a ulimit below
+1280K will kill every process.
+
+To test, do:
+
+ 'ulimit -s 15; ls'
+
+before and after the patch is applied. Before it's applied, 'ls' should
+be killed. After the patch is applied, 'ls' should no longer be killed.
+
+A stack limit of 15KB since it's small enough to trigger 20*PAGE_SIZE.
+Also 15KB not a multiple of PAGE_SIZE, which is a trickier case to handle
+correctly with this code.
+
+4K pages should be fine to test with.
+
+[kosaki.motohiro@jp.fujitsu.com: cleanup]
+[akpm@linux-foundation.org: cleanup cleanup]
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Cc: Americo Wang <xiyou.wangcong@gmail.com>
+Cc: Anton Blanchard <anton@samba.org>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: James Morris <jmorris@namei.org>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Serge Hallyn <serue@us.ibm.com>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/exec.c | 21 +++++++++++++++++++--
+ 1 file changed, 19 insertions(+), 2 deletions(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -572,6 +572,9 @@ int setup_arg_pages(struct linux_binprm
+ struct vm_area_struct *prev = NULL;
+ unsigned long vm_flags;
+ unsigned long stack_base;
++ unsigned long stack_size;
++ unsigned long stack_expand;
++ unsigned long rlim_stack;
+
+ #ifdef CONFIG_STACK_GROWSUP
+ /* Limit stack size to 1GB */
+@@ -628,10 +631,24 @@ int setup_arg_pages(struct linux_binprm
+ goto out_unlock;
+ }
+
++ stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
++ stack_size = vma->vm_end - vma->vm_start;
++ /*
++ * Align this down to a page boundary as expand_stack
++ * will align it up.
++ */
++ rlim_stack = rlimit(RLIMIT_STACK) & PAGE_MASK;
++ rlim_stack = min(rlim_stack, stack_size);
+ #ifdef CONFIG_STACK_GROWSUP
+- stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
++ if (stack_size + stack_expand > rlim_stack)
++ stack_base = vma->vm_start + rlim_stack;
++ else
++ stack_base = vma->vm_end + stack_expand;
+ #else
+- stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
++ if (stack_size + stack_expand > rlim_stack)
++ stack_base = vma->vm_end - rlim_stack;
++ else
++ stack_base = vma->vm_start - stack_expand;
+ #endif
+ ret = expand_stack(vma, stack_base);
+ if (ret)
--- /dev/null
+From 7e55a70c5b9a57c12f49c44b0847c9343d4f54e4 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Wed, 13 Jan 2010 13:33:12 -0700
+Subject: ioat: fix infinite timeout checking in ioat2_quiesce
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 7e55a70c5b9a57c12f49c44b0847c9343d4f54e4 upstream.
+
+Fix typo in ioat2_quiesce. check 'tmo' is zero, not 'end'. Also applies
+to 2.6.32.3
+
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/dma/ioat/dma_v2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/dma/ioat/dma_v2.c
++++ b/drivers/dma/ioat/dma_v2.c
+@@ -249,7 +249,7 @@ int ioat2_quiesce(struct ioat_chan_commo
+ if (is_ioat_active(status) || is_ioat_idle(status))
+ ioat_suspend(chan);
+ while (is_ioat_active(status) || is_ioat_idle(status)) {
+- if (end && time_after(jiffies, end)) {
++ if (tmo && time_after(jiffies, end)) {
+ err = -ETIMEDOUT;
+ break;
+ }
--- /dev/null
+From 973e9a2795b3b41d8408a0bb6f87b783c5efc88a Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@opensource.wolfsonmicro.com>
+Date: Thu, 11 Feb 2010 19:20:48 +0000
+Subject: regulator: Fix display of null constraints for regulators
+
+From: Mark Brown <broonie@opensource.wolfsonmicro.com>
+
+commit 973e9a2795b3b41d8408a0bb6f87b783c5efc88a upstream.
+
+If the regulator constraints are empty and there is no voltage
+reported then nothing will be added to the text displayed for the
+constraints, leading to random stack data being printed. This is
+unlikely to happen for practical regulators since most will at
+least report a voltage but should still be fixed.
+
+Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
+Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/regulator/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -640,7 +640,7 @@ static int suspend_prepare(struct regula
+ static void print_constraints(struct regulator_dev *rdev)
+ {
+ struct regulation_constraints *constraints = rdev->constraints;
+- char buf[80];
++ char buf[80] = "";
+ int count;
+
+ if (rdev->desc->type == REGULATOR_VOLTAGE) {
--- /dev/null
+From 3e10e716abf3c71bdb5d86b8f507f9e72236c9cd Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Thu, 19 Nov 2009 17:16:37 +0100
+Subject: resource: add helpers for fetching rlimits
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 3e10e716abf3c71bdb5d86b8f507f9e72236c9cd upstream.
+
+We want to be sure that compiler fetches the limit variable only
+once, so add helpers for fetching current and maximal resource
+limits which do that.
+
+Add them to sched.h (instead of resource.h) due to circular dependency
+ sched.h->resource.h->task_struct
+Alternative would be to create a separate res_access.h or similar.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: James Morris <jmorris@namei.org>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/linux/sched.h | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/include/linux/sched.h
++++ b/include/linux/sched.h
+@@ -2583,6 +2583,28 @@ static inline void mm_init_owner(struct
+
+ #define TASK_STATE_TO_CHAR_STR "RSDTtZX"
+
++static inline unsigned long task_rlimit(const struct task_struct *tsk,
++ unsigned int limit)
++{
++ return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_cur);
++}
++
++static inline unsigned long task_rlimit_max(const struct task_struct *tsk,
++ unsigned int limit)
++{
++ return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_max);
++}
++
++static inline unsigned long rlimit(unsigned int limit)
++{
++ return task_rlimit(current, limit);
++}
++
++static inline unsigned long rlimit_max(unsigned int limit)
++{
++ return task_rlimit_max(current, limit);
++}
++
+ #endif /* __KERNEL__ */
+
+ #endif
drm-i915-add-malata-pc-81005-to-acpi-lid-quirk-list.patch
usb-r8a66597-hcd-flush-the-d-cache-for-the-pipe-in-transfer-buffers.patch
i2c-tiny-usb-fix-on-big-endian-systems.patch
+drm-i915-handle-fbc-and-self-refresh-better.patch
+drm-i915-increase-fb-alignment-to-64k.patch
+drm-i915-update-write_domains-on-active-list-after-flush.patch
+regulator-fix-display-of-null-constraints-for-regulators.patch
+alsa-hda-intel-avoid-divide-by-zero-crash.patch
+cpufreq-fix-use-after-free-of-struct-powernow_k8_data.patch
+freeze_bdev-don-t-deactivate-successfully-frozen-ms_rdonly-sb.patch
+cciss-make-cciss_seq_show-handle-holes-in-the-h-drv-array.patch
+vgaarb-fix-incorrect-dereference-of-userspace-pointer.patch
+ioat-fix-infinite-timeout-checking-in-ioat2_quiesce.patch
+resource-add-helpers-for-fetching-rlimits.patch
+fs-exec.c-restrict-initial-stack-space-expansion-to-rlimit.patch
+cifs-fix-length-calculation-for-converted-unicode-readdir-names.patch
--- /dev/null
+From 77c1ff3982c6b36961725dd19e872a1c07df7f3b Mon Sep 17 00:00:00 2001
+From: Andy Getzendanner <james.getzendanner@students.olin.edu>
+Date: Thu, 11 Feb 2010 14:04:48 +1000
+Subject: vgaarb: fix incorrect dereference of userspace pointer.
+
+From: Andy Getzendanner <james.getzendanner@students.olin.edu>
+
+commit 77c1ff3982c6b36961725dd19e872a1c07df7f3b upstream.
+
+This patch corrects a userspace pointer dereference in the VGA arbiter
+in 2.6.32.1.
+
+copy_from_user() is used at line 822 to copy the contents of buf into
+kbuf, but a call to strncmp() on line 964 uses buf rather than kbuf. This
+problem led to a GPF in strncmp() when X was started on my x86_32 systems.
+ X triggered the behavior with a write of "target PCI:0000:01:00.0" to
+/dev/vga_arbiter.
+
+The patch has been tested against 2.6.32.1 and observed to correct the GPF
+observed when starting X or manually writing the string "target
+PCI:0000:01:00.0" to /dev/vga_arbiter.
+
+Signed-off-by: Andy Getzendanner <james.getzendanner@students.olin.edu>
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/vga/vgaarb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/vga/vgaarb.c
++++ b/drivers/gpu/vga/vgaarb.c
+@@ -961,7 +961,7 @@ static ssize_t vga_arb_write(struct file
+ remaining -= 7;
+ pr_devel("client 0x%p called 'target'\n", priv);
+ /* if target is default */
+- if (!strncmp(buf, "default", 7))
++ if (!strncmp(kbuf, "default", 7))
+ pdev = pci_dev_get(vga_default_device());
+ else {
+ if (!vga_pci_str_to_vars(curr_pos, remaining,
projects / thirdparty / kernel / stable-queue.git / commitdiff
