From: Greg Kroah-Hartman Date: Fri, 12 Feb 2010 20:43:17 +0000 (-0800) Subject: more .32 patches X-Git-Tag: v2.6.32.9~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7f785a88f88cc30fc61b6b7ddd847c7796e45f7a;p=thirdparty%2Fkernel%2Fstable-queue.git more .32 patches --- diff --git a/queue-2.6.32/alsa-hda-intel-avoid-divide-by-zero-crash.patch b/queue-2.6.32/alsa-hda-intel-avoid-divide-by-zero-crash.patch new file mode 100644 index 00000000000..1a16c7a0cab --- /dev/null +++ b/queue-2.6.32/alsa-hda-intel-avoid-divide-by-zero-crash.patch @@ -0,0 +1,42 @@ +From fed08d036f2aabd8d0c684439de37f8ebec2bbc2 Mon Sep 17 00:00:00 2001 +From: Jody Bruchon +Date: Sat, 6 Feb 2010 10:46:26 -0500 +Subject: ALSA: hda-intel: Avoid divide by zero crash + +From: Jody Bruchon + +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 +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-2.6.32/cciss-make-cciss_seq_show-handle-holes-in-the-h-drv-array.patch b/queue-2.6.32/cciss-make-cciss_seq_show-handle-holes-in-the-h-drv-array.patch new file mode 100644 index 00000000000..50c6c2c6789 --- /dev/null +++ b/queue-2.6.32/cciss-make-cciss_seq_show-handle-holes-in-the-h-drv-array.patch @@ -0,0 +1,40 @@ +From 531c2dc70d339c5dfa8c3eb628c3459dc6f3a075 Mon Sep 17 00:00:00 2001 +From: Stephen M. Cameron +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 + +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 +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-2.6.32/cifs-fix-length-calculation-for-converted-unicode-readdir-names.patch b/queue-2.6.32/cifs-fix-length-calculation-for-converted-unicode-readdir-names.patch new file mode 100644 index 00000000000..a342f5b3008 --- /dev/null +++ b/queue-2.6.32/cifs-fix-length-calculation-for-converted-unicode-readdir-names.patch @@ -0,0 +1,44 @@ +From f12f98dba6ea1517cd7fbb912208893b9c014c15 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Fri, 5 Feb 2010 13:14:00 -0500 +Subject: cifs: fix length calculation for converted unicode readdir names + +From: Jeff Layton + +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 +Acked-by: Dave Kleikamp +Signed-off-by: Jeff Layton +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-2.6.32/cpufreq-fix-use-after-free-of-struct-powernow_k8_data.patch b/queue-2.6.32/cpufreq-fix-use-after-free-of-struct-powernow_k8_data.patch new file mode 100644 index 00000000000..44d177c8b17 --- /dev/null +++ b/queue-2.6.32/cpufreq-fix-use-after-free-of-struct-powernow_k8_data.patch @@ -0,0 +1,51 @@ +From 557a701c16553b0b691dbb64ef30361115a80f64 Mon Sep 17 00:00:00 2001 +From: Thomas Renninger +Date: Mon, 14 Dec 2009 11:44:15 +0100 +Subject: CPUFREQ: Fix use after free of struct powernow_k8_data + +From: Thomas Renninger + +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 +Tested-by: Michal Schmidt +Signed-off-by: Dave Jones +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-2.6.32/drm-i915-handle-fbc-and-self-refresh-better.patch b/queue-2.6.32/drm-i915-handle-fbc-and-self-refresh-better.patch new file mode 100644 index 00000000000..995f6b4eb72 --- /dev/null +++ b/queue-2.6.32/drm-i915-handle-fbc-and-self-refresh-better.patch @@ -0,0 +1,46 @@ +From ee25df2bc379728c45d81e04cf87984db1425edf Mon Sep 17 00:00:00 2001 +From: Jesse Barnes +Date: Sat, 6 Feb 2010 10:41:53 -0800 +Subject: drm/i915: handle FBC and self-refresh better + +From: Jesse Barnes + +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 +Signed-off-by: Jesse Barnes +Tested-by: Julien Cristau (fd.o #25371) +Signed-off-by: Eric Anholt +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-2.6.32/drm-i915-increase-fb-alignment-to-64k.patch b/queue-2.6.32/drm-i915-increase-fb-alignment-to-64k.patch new file mode 100644 index 00000000000..4e61acf64d1 --- /dev/null +++ b/queue-2.6.32/drm-i915-increase-fb-alignment-to-64k.patch @@ -0,0 +1,39 @@ +From fd2e8ea597222b8f38ae8948776a61ea7958232e Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 9 Feb 2010 14:14:36 +0000 +Subject: drm/i915: Increase fb alignment to 64k + +From: Chris Wilson + +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 +Signed-off-by: Eric Anholt +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-2.6.32/drm-i915-update-write_domains-on-active-list-after-flush.patch b/queue-2.6.32/drm-i915-update-write_domains-on-active-list-after-flush.patch new file mode 100644 index 00000000000..b8b2aa13953 --- /dev/null +++ b/queue-2.6.32/drm-i915-update-write_domains-on-active-list-after-flush.patch @@ -0,0 +1,177 @@ +From 99fcb766a3a50466fe31d743260a3400c1aee855 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sun, 7 Feb 2010 16:20:18 +0100 +Subject: drm/i915: Update write_domains on active list after flush. + +From: Daniel Vetter + +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 , 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 +Signed-off-by: Chris Wilson +Tested-by: Adam Lantos +Signed-off-by: Eric Anholt +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-2.6.32/freeze_bdev-don-t-deactivate-successfully-frozen-ms_rdonly-sb.patch b/queue-2.6.32/freeze_bdev-don-t-deactivate-successfully-frozen-ms_rdonly-sb.patch new file mode 100644 index 00000000000..d3c758af819 --- /dev/null +++ b/queue-2.6.32/freeze_bdev-don-t-deactivate-successfully-frozen-ms_rdonly-sb.patch @@ -0,0 +1,66 @@ +From 4b06e5b9ad8abb20105b2b25e42c509ebe9b2d76 Mon Sep 17 00:00:00 2001 +From: Jun'ichi Nomura +Date: Fri, 29 Jan 2010 09:56:22 +0900 +Subject: freeze_bdev: don't deactivate successfully frozen MS_RDONLY sb + +From: Jun'ichi Nomura + +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 +Tested-by: Thomas Backlund +Signed-off-by: Jun'ichi Nomura +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- 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: diff --git a/queue-2.6.32/fs-exec.c-restrict-initial-stack-space-expansion-to-rlimit.patch b/queue-2.6.32/fs-exec.c-restrict-initial-stack-space-expansion-to-rlimit.patch new file mode 100644 index 00000000000..c3a04b71ccd --- /dev/null +++ b/queue-2.6.32/fs-exec.c-restrict-initial-stack-space-expansion-to-rlimit.patch @@ -0,0 +1,93 @@ +From 803bf5ec259941936262d10ecc84511b76a20921 Mon Sep 17 00:00:00 2001 +From: Michael Neuling +Date: Wed, 10 Feb 2010 13:56:42 -0800 +Subject: fs/exec.c: restrict initial stack space expansion to rlimit + +From: Michael Neuling + +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 +Signed-off-by: KOSAKI Motohiro +Cc: Americo Wang +Cc: Anton Blanchard +Cc: Oleg Nesterov +Cc: James Morris +Cc: Ingo Molnar +Cc: Serge Hallyn +Cc: Benjamin Herrenschmidt +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-2.6.32/ioat-fix-infinite-timeout-checking-in-ioat2_quiesce.patch b/queue-2.6.32/ioat-fix-infinite-timeout-checking-in-ioat2_quiesce.patch new file mode 100644 index 00000000000..5ac67aacd26 --- /dev/null +++ b/queue-2.6.32/ioat-fix-infinite-timeout-checking-in-ioat2_quiesce.patch @@ -0,0 +1,30 @@ +From 7e55a70c5b9a57c12f49c44b0847c9343d4f54e4 Mon Sep 17 00:00:00 2001 +From: Dan Williams +Date: Wed, 13 Jan 2010 13:33:12 -0700 +Subject: ioat: fix infinite timeout checking in ioat2_quiesce + +From: Dan Williams + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-2.6.32/regulator-fix-display-of-null-constraints-for-regulators.patch b/queue-2.6.32/regulator-fix-display-of-null-constraints-for-regulators.patch new file mode 100644 index 00000000000..3d3a972dc24 --- /dev/null +++ b/queue-2.6.32/regulator-fix-display-of-null-constraints-for-regulators.patch @@ -0,0 +1,34 @@ +From 973e9a2795b3b41d8408a0bb6f87b783c5efc88a Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Thu, 11 Feb 2010 19:20:48 +0000 +Subject: regulator: Fix display of null constraints for regulators + +From: Mark Brown + +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 +Signed-off-by: Liam Girdwood +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-2.6.32/resource-add-helpers-for-fetching-rlimits.patch b/queue-2.6.32/resource-add-helpers-for-fetching-rlimits.patch new file mode 100644 index 00000000000..174a247f150 --- /dev/null +++ b/queue-2.6.32/resource-add-helpers-for-fetching-rlimits.patch @@ -0,0 +1,59 @@ +From 3e10e716abf3c71bdb5d86b8f507f9e72236c9cd Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Thu, 19 Nov 2009 17:16:37 +0100 +Subject: resource: add helpers for fetching rlimits + +From: Jiri Slaby + +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 +Cc: James Morris +Cc: Heiko Carstens +Cc: Andrew Morton +Cc: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-2.6.32/series b/queue-2.6.32/series index 317cda1f293..c43ea16fe46 100644 --- a/queue-2.6.32/series +++ b/queue-2.6.32/series @@ -16,3 +16,16 @@ drm-i915-fix-the-incorrect-dmi-string-for-samsung-sx20s-laptop.patch 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 diff --git a/queue-2.6.32/vgaarb-fix-incorrect-dereference-of-userspace-pointer.patch b/queue-2.6.32/vgaarb-fix-incorrect-dereference-of-userspace-pointer.patch new file mode 100644 index 00000000000..bd41945672b --- /dev/null +++ b/queue-2.6.32/vgaarb-fix-incorrect-dereference-of-userspace-pointer.patch @@ -0,0 +1,43 @@ +From 77c1ff3982c6b36961725dd19e872a1c07df7f3b Mon Sep 17 00:00:00 2001 +From: Andy Getzendanner +Date: Thu, 11 Feb 2010 14:04:48 +1000 +Subject: vgaarb: fix incorrect dereference of userspace pointer. + +From: Andy Getzendanner + +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 +Cc: Jesse Barnes +Signed-off-by: Andrew Morton +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + 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,