From 1cc97653312a4ee23e1bf921327e936899882b80 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 7 May 2010 14:10:00 -0700 Subject: [PATCH] .32 stuff --- ...arameter-acpi_sleep-sci_force_enable.patch | 118 ++++++++++++++++++ ...toshiba-satellite-p500-pspgsc-01800t.patch | 12 +- ...are_invalid-in-credentials-debugging.patch | 75 +++++++++++ ...ndencies-between-dccp-and-dccp_probe.patch | 45 +++++++ ...less-p54-txrx.c-fix-off-by-one-error.patch | 32 +++++ ...x-tiling-limits-for-i915-class-hw-v2.patch | 100 +++++++++++++++ ...alculate-number-of-blocks-for-fiemap.patch | 52 ++++++++ ...cognised-decompressor-when-unpacking.patch | 43 +++++++ ...llocext-error-in-resizing-filesystem.patch | 52 ++++++++ ...-lba28-boundary-old-bug-but-nasty-v2.patch | 39 ++++++ .../p54pci-rx-frame-length-check.patch | 52 ++++++++ ...nsure-we-re-enable-devices-on-resume.patch | 45 +++++++ queue-2.6.32/series | 11 ++ 13 files changed, 671 insertions(+), 5 deletions(-) create mode 100644 queue-2.6.32/acpi-introduce-kernel-parameter-acpi_sleep-sci_force_enable.patch create mode 100644 queue-2.6.32/cred-fix-a-race-in-creds_are_invalid-in-credentials-debugging.patch create mode 100644 queue-2.6.32/dccp_probe-fix-module-load-dependencies-between-dccp-and-dccp_probe.patch create mode 100644 queue-2.6.32/drivers-net-wireless-p54-txrx.c-fix-off-by-one-error.patch create mode 100644 queue-2.6.32/drm-i915-fix-tiling-limits-for-i915-class-hw-v2.patch create mode 100644 queue-2.6.32/ext4-correctly-calculate-number-of-blocks-for-fiemap.patch create mode 100644 queue-2.6.32/initramfs-handle-unrecognised-decompressor-when-unpacking.patch create mode 100644 queue-2.6.32/jfs-fix-diallocext-error-in-resizing-filesystem.patch create mode 100644 queue-2.6.32/libata-fix-accesses-at-lba28-boundary-old-bug-but-nasty-v2.patch create mode 100644 queue-2.6.32/p54pci-rx-frame-length-check.patch create mode 100644 queue-2.6.32/pci-ensure-we-re-enable-devices-on-resume.patch diff --git a/queue-2.6.32/acpi-introduce-kernel-parameter-acpi_sleep-sci_force_enable.patch b/queue-2.6.32/acpi-introduce-kernel-parameter-acpi_sleep-sci_force_enable.patch new file mode 100644 index 00000000000..635cb967114 --- /dev/null +++ b/queue-2.6.32/acpi-introduce-kernel-parameter-acpi_sleep-sci_force_enable.patch @@ -0,0 +1,118 @@ +From d7f0eea9e431e1b8b0742a74db1a9490730b2a25 Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Wed, 30 Dec 2009 15:36:42 +0800 +Subject: ACPI: introduce kernel parameter acpi_sleep=sci_force_enable + +From: Zhang Rui + +commit d7f0eea9e431e1b8b0742a74db1a9490730b2a25 upstream. + +Introduce kernel parameter acpi_sleep=sci_force_enable + +some laptop requires SCI_EN being set directly on resume, +or else they hung somewhere in the resume code path. + +We already have a blacklist for these laptops but we still need +this option, especially when debugging some suspend/resume problems, +in case there are systems that need this workaround and are not yet +in the blacklist. + +Signed-off-by: Zhang Rui +Acked-by: Rafael J. Wysocki +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/kernel-parameters.txt | 5 ++++- + arch/x86/kernel/acpi/sleep.c | 2 ++ + drivers/acpi/sleep.c | 29 +++++++++++++++++------------ + include/linux/acpi.h | 1 + + 4 files changed, 24 insertions(+), 13 deletions(-) + +--- a/Documentation/kernel-parameters.txt ++++ b/Documentation/kernel-parameters.txt +@@ -241,7 +241,7 @@ and is between 256 and 4096 characters. + + acpi_sleep= [HW,ACPI] Sleep options + Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, +- old_ordering, s4_nonvs } ++ old_ordering, s4_nonvs, sci_force_enable } + See Documentation/power/video.txt for information on + s3_bios and s3_mode. + s3_beep is for debugging; it makes the PC's speaker beep +@@ -254,6 +254,9 @@ and is between 256 and 4096 characters. + of _PTS is used by default). + s4_nonvs prevents the kernel from saving/restoring the + ACPI NVS memory during hibernation. ++ sci_force_enable causes the kernel to set SCI_EN directly ++ on resume from S1/S3 (which is against the ACPI spec, ++ but some broken systems don't work without it). + + acpi_use_timer_override [HW,ACPI] + Use timer override. For some broken Nvidia NF5 boards +--- a/arch/x86/kernel/acpi/sleep.c ++++ b/arch/x86/kernel/acpi/sleep.c +@@ -162,6 +162,8 @@ static int __init acpi_sleep_setup(char + #endif + if (strncmp(str, "old_ordering", 12) == 0) + acpi_old_suspend_ordering(); ++ if (strncmp(str, "sci_force_enable", 16) == 0) ++ acpi_set_sci_en_on_resume(); + str = strchr(str, ','); + if (str != NULL) + str += strspn(str, ", \t"); +--- a/drivers/acpi/sleep.c ++++ b/drivers/acpi/sleep.c +@@ -81,6 +81,23 @@ static int acpi_sleep_prepare(u32 acpi_s + #ifdef CONFIG_ACPI_SLEEP + static u32 acpi_target_sleep_state = ACPI_STATE_S0; + /* ++ * According to the ACPI specification the BIOS should make sure that ACPI is ++ * enabled and SCI_EN bit is set on wake-up from S1 - S3 sleep states. Still, ++ * some BIOSes don't do that and therefore we use acpi_enable() to enable ACPI ++ * on such systems during resume. Unfortunately that doesn't help in ++ * particularly pathological cases in which SCI_EN has to be set directly on ++ * resume, although the specification states very clearly that this flag is ++ * owned by the hardware. The set_sci_en_on_resume variable will be set in such ++ * cases. ++ */ ++static bool set_sci_en_on_resume; ++ ++void __init acpi_set_sci_en_on_resume(void) ++{ ++ set_sci_en_on_resume = true; ++} ++ ++/* + * ACPI 1.0 wants us to execute _PTS before suspending devices, so we allow the + * user to request that behavior by using the 'acpi_old_suspend_ordering' + * kernel command line option that causes the following variable to be set. +@@ -170,18 +187,6 @@ static void acpi_pm_end(void) + #endif /* CONFIG_ACPI_SLEEP */ + + #ifdef CONFIG_SUSPEND +-/* +- * According to the ACPI specification the BIOS should make sure that ACPI is +- * enabled and SCI_EN bit is set on wake-up from S1 - S3 sleep states. Still, +- * some BIOSes don't do that and therefore we use acpi_enable() to enable ACPI +- * on such systems during resume. Unfortunately that doesn't help in +- * particularly pathological cases in which SCI_EN has to be set directly on +- * resume, although the specification states very clearly that this flag is +- * owned by the hardware. The set_sci_en_on_resume variable will be set in such +- * cases. +- */ +-static bool set_sci_en_on_resume; +- + extern void do_suspend_lowlevel(void); + + static u32 acpi_suspend_states[] = { +--- a/include/linux/acpi.h ++++ b/include/linux/acpi.h +@@ -251,6 +251,7 @@ int acpi_check_mem_region(resource_size_ + void __init acpi_no_s4_hw_signature(void); + void __init acpi_old_suspend_ordering(void); + void __init acpi_s4_no_nvs(void); ++void __init acpi_set_sci_en_on_resume(void); + #endif /* CONFIG_PM_SLEEP */ + + struct acpi_osc_context { diff --git a/queue-2.6.32/alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-p500-pspgsc-01800t.patch b/queue-2.6.32/alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-p500-pspgsc-01800t.patch index fa2c6e235f6..1efd845e24e 100644 --- a/queue-2.6.32/alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-p500-pspgsc-01800t.patch +++ b/queue-2.6.32/alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-p500-pspgsc-01800t.patch @@ -19,15 +19,17 @@ Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman -diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c -index e1323e4..924c122 100644 +--- + sound/pci/hda/patch_conexant.c | 1 + + 1 file changed, 1 insertion(+) + --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c -@@ -2842,6 +2842,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { +@@ -2350,6 +2350,7 @@ static struct snd_pci_quirk cxt5066_cfg_ + SND_PCI_QUIRK(0x1028, 0x02f5, "Dell", CXT5066_DELL_LAPTOP), SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), - SND_PCI_QUIRK(0x1028, 0x0402, "Dell Vostro", CXT5066_DELL_VOSTO), + SND_PCI_QUIRK(0x1179, 0xff50, "Toshiba Satellite P500-PSPGSC-01800T", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x1179, 0xffe0, "Toshiba Satellite Pro T130-15F", CXT5066_OLPC_XO_1_5), - SND_PCI_QUIRK(0x17aa, 0x3a0d, "ideapad", CXT5066_IDEAPAD), {} + }; diff --git a/queue-2.6.32/cred-fix-a-race-in-creds_are_invalid-in-credentials-debugging.patch b/queue-2.6.32/cred-fix-a-race-in-creds_are_invalid-in-credentials-debugging.patch new file mode 100644 index 00000000000..62882b3b1a2 --- /dev/null +++ b/queue-2.6.32/cred-fix-a-race-in-creds_are_invalid-in-credentials-debugging.patch @@ -0,0 +1,75 @@ +From e134d200d57d43b171dcb0b55c178a1a0c7db14a Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Wed, 21 Apr 2010 10:28:25 +0100 +Subject: CRED: Fix a race in creds_are_invalid() in credentials debugging + +From: David Howells + +commit e134d200d57d43b171dcb0b55c178a1a0c7db14a upstream. + +creds_are_invalid() reads both cred->usage and cred->subscribers and then +compares them to make sure the number of processes subscribed to a cred struct +never exceeds the refcount of that cred struct. + +The problem is that this can cause a race with both copy_creds() and +exit_creds() as the two counters, whilst they are of atomic_t type, are only +atomic with respect to themselves, and not atomic with respect to each other. + +This means that if creds_are_invalid() can read the values on one CPU whilst +they're being modified on another CPU, and so can observe an evolving state in +which the subscribers count now is greater than the usage count a moment +before. + +Switching the order in which the counts are read cannot help, so the thing to +do is to remove that particular check. + +I had considered rechecking the values to see if they're in flux if the test +fails, but I can't guarantee they won't appear the same, even if they've +changed several times in the meantime. + +Note that this can only happen if CONFIG_DEBUG_CREDENTIALS is enabled. + +The problem is only likely to occur with multithreaded programs, and can be +tested by the tst-eintr1 program from glibc's "make check". The symptoms look +like: + + CRED: Invalid credentials + CRED: At include/linux/cred.h:240 + CRED: Specified credentials: ffff88003dda5878 [real][eff] + CRED: ->magic=43736564, put_addr=(null) + CRED: ->usage=766, subscr=766 + CRED: ->*uid = { 0,0,0,0 } + CRED: ->*gid = { 0,0,0,0 } + CRED: ->security is ffff88003d72f538 + CRED: ->security {359, 359} + ------------[ cut here ]------------ + kernel BUG at kernel/cred.c:850! + ... + RIP: 0010:[] [] __invalid_creds+0x4e/0x52 + ... + Call Trace: + [] copy_creds+0x6b/0x23f + +Note the ->usage=766 and subscr=766. The values appear the same because +they've been re-read since the check was made. + +Reported-by: Roland McGrath +Signed-off-by: David Howells +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cred.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/kernel/cred.c ++++ b/kernel/cred.c +@@ -786,8 +786,6 @@ bool creds_are_invalid(const struct cred + { + if (cred->magic != CRED_MAGIC) + return true; +- if (atomic_read(&cred->usage) < atomic_read(&cred->subscribers)) +- return true; + #ifdef CONFIG_SECURITY_SELINUX + if (selinux_is_enabled()) { + if ((unsigned long) cred->security < PAGE_SIZE) diff --git a/queue-2.6.32/dccp_probe-fix-module-load-dependencies-between-dccp-and-dccp_probe.patch b/queue-2.6.32/dccp_probe-fix-module-load-dependencies-between-dccp-and-dccp_probe.patch new file mode 100644 index 00000000000..1636226013e --- /dev/null +++ b/queue-2.6.32/dccp_probe-fix-module-load-dependencies-between-dccp-and-dccp_probe.patch @@ -0,0 +1,45 @@ +From 38ff3e6bb987ec583268da8eb22628293095d43b Mon Sep 17 00:00:00 2001 +From: Neil Horman +Date: Fri, 15 Jan 2010 01:40:55 -0800 +Subject: dccp_probe: Fix module load dependencies between dccp and dccp_probe + +From: Neil Horman + +commit 38ff3e6bb987ec583268da8eb22628293095d43b upstream. + +This was just recently reported to me. When built as modules, the +dccp_probe module has a silent dependency on the dccp module. This +stems from the fact that the module_init routine of dccp_probe +registers a jprobe on the dccp_sendmsg symbol. Since the symbol is +only referenced as a text string (the .symbol_name field in the jprobe +struct) rather than the address of the symbol itself, depmod never +picks this dependency up, and so if you load the dccp_probe module +without the dccp module loaded, the register_jprobe call fails with an +-EINVAL, and the whole module load fails. + +The fix is pretty easy, we can just wrap the register_jprobe call in a +try_then_request_module call, which forces the dependency to get +satisfied prior to the probe registration. + +Signed-off-by: Neil Horman +Acked-by: Arnaldo Carvalho de Melo +Signed-off-by: David S. Miller +Cc: maximilian attems +Signed-off-by: Greg Kroah-Hartman + +--- + net/dccp/probe.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/dccp/probe.c ++++ b/net/dccp/probe.c +@@ -164,7 +164,8 @@ static __init int dccpprobe_init(void) + if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops)) + goto err0; + +- ret = register_jprobe(&dccp_send_probe); ++ ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0), ++ "dccp"); + if (ret) + goto err1; + diff --git a/queue-2.6.32/drivers-net-wireless-p54-txrx.c-fix-off-by-one-error.patch b/queue-2.6.32/drivers-net-wireless-p54-txrx.c-fix-off-by-one-error.patch new file mode 100644 index 00000000000..ade951bc5b3 --- /dev/null +++ b/queue-2.6.32/drivers-net-wireless-p54-txrx.c-fix-off-by-one-error.patch @@ -0,0 +1,32 @@ +From 088ea189c4c75cdf211146faa4b341a0f7476be6 Mon Sep 17 00:00:00 2001 +From: Darren Jenkins +Date: Wed, 17 Feb 2010 23:40:15 +1100 +Subject: drivers/net/wireless/p54/txrx.c Fix off by one error + +From: Darren Jenkins + +commit 088ea189c4c75cdf211146faa4b341a0f7476be6 upstream. + +fix off by one error in the queue size check of p54_tx_qos_accounting_alloc() + +Coverity CID: 13314 + +Signed-off-by: Darren Jenkins +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/p54/txrx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/p54/txrx.c ++++ b/drivers/net/wireless/p54/txrx.c +@@ -186,7 +186,7 @@ static int p54_tx_qos_accounting_alloc(s + struct ieee80211_tx_queue_stats *queue; + unsigned long flags; + +- if (WARN_ON(p54_queue > P54_QUEUE_NUM)) ++ if (WARN_ON(p54_queue >= P54_QUEUE_NUM)) + return -EINVAL; + + queue = &priv->tx_stats[p54_queue]; diff --git a/queue-2.6.32/drm-i915-fix-tiling-limits-for-i915-class-hw-v2.patch b/queue-2.6.32/drm-i915-fix-tiling-limits-for-i915-class-hw-v2.patch new file mode 100644 index 00000000000..1452902f06d --- /dev/null +++ b/queue-2.6.32/drm-i915-fix-tiling-limits-for-i915-class-hw-v2.patch @@ -0,0 +1,100 @@ +From c36a2a6de59e4a141a68b7575de837d3b0bd96b3 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sat, 17 Apr 2010 15:12:03 +0200 +Subject: drm/i915: fix tiling limits for i915 class hw v2 + +From: Daniel Vetter + +commit c36a2a6de59e4a141a68b7575de837d3b0bd96b3 upstream. + +Current code is definitely crap: Largest pitch allowed spills into +the TILING_Y bit of the fence registers ... :( + +I've rewritten the limits check under the assumption that 3rd gen hw +has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an +otherwise totally misleading XXX comment. + +This bug mostly resulted in tiling-corrupted pixmaps because the kernel +allowed too wide buffers to be tiled. Bug brought to the light by the +xf86-video-intel 2.11 release because that unconditionally enabled +tiling for pixmaps, relying on the kernel to check things. Tiling for +the framebuffer was not affected because the ddx does some additional +checks there ensure the buffer is within hw-limits. + +v2: Instead of computing the value that would be written into the +hw fence registers and then checking the limits simply check whether +the stride is above the 8kb limit. To better document the hw, add +some WARN_ONs in i915_write_fence_reg like I've done for the i830 +case (using the right limits). + +Signed-off-by: Daniel Vetter +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449 +Tested-by: Alexander Lam +Signed-off-by: Eric Anholt +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem.c | 6 ++++++ + drivers/gpu/drm/i915/i915_gem_tiling.c | 22 +++++++++------------- + drivers/gpu/drm/i915/i915_reg.h | 2 +- + 3 files changed, 16 insertions(+), 14 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -2334,6 +2334,12 @@ static void i915_write_fence_reg(struct + pitch_val = obj_priv->stride / tile_width; + pitch_val = ffs(pitch_val) - 1; + ++ if (obj_priv->tiling_mode == I915_TILING_Y && ++ HAS_128_BYTE_Y_TILING(dev)) ++ WARN_ON(pitch_val > I830_FENCE_MAX_PITCH_VAL); ++ else ++ WARN_ON(pitch_val > I915_FENCE_MAX_PITCH_VAL); ++ + val = obj_priv->gtt_offset; + if (obj_priv->tiling_mode == I915_TILING_Y) + val |= 1 << I830_FENCE_TILING_Y_SHIFT; +--- a/drivers/gpu/drm/i915/i915_gem_tiling.c ++++ b/drivers/gpu/drm/i915/i915_gem_tiling.c +@@ -353,21 +353,17 @@ i915_tiling_ok(struct drm_device *dev, i + * reg, so dont bother to check the size */ + if (stride / 128 > I965_FENCE_MAX_PITCH_VAL) + return false; +- } else if (IS_I9XX(dev)) { +- uint32_t pitch_val = ffs(stride / tile_width) - 1; +- +- /* XXX: For Y tiling, FENCE_MAX_PITCH_VAL is actually 6 (8KB) +- * instead of 4 (2KB) on 945s. +- */ +- if (pitch_val > I915_FENCE_MAX_PITCH_VAL || +- size > (I830_FENCE_MAX_SIZE_VAL << 20)) ++ } else if (IS_I9XX(dev) || IS_I8XX(dev)) { ++ if (stride > 8192) + return false; +- } else { +- uint32_t pitch_val = ffs(stride / tile_width) - 1; + +- if (pitch_val > I830_FENCE_MAX_PITCH_VAL || +- size > (I830_FENCE_MAX_SIZE_VAL << 19)) +- return false; ++ if (IS_I9XX(dev)) { ++ if (size > I830_FENCE_MAX_SIZE_VAL << 20) ++ return false; ++ } else { ++ if (size > I830_FENCE_MAX_SIZE_VAL << 19) ++ return false; ++ } + } + + /* 965+ just needs multiples of tile width */ +--- a/drivers/gpu/drm/i915/i915_reg.h ++++ b/drivers/gpu/drm/i915/i915_reg.h +@@ -214,7 +214,7 @@ + #define I830_FENCE_SIZE_BITS(size) ((ffs((size) >> 19) - 1) << 8) + #define I830_FENCE_PITCH_SHIFT 4 + #define I830_FENCE_REG_VALID (1<<0) +-#define I915_FENCE_MAX_PITCH_VAL 0x10 ++#define I915_FENCE_MAX_PITCH_VAL 4 + #define I830_FENCE_MAX_PITCH_VAL 6 + #define I830_FENCE_MAX_SIZE_VAL (1<<8) + diff --git a/queue-2.6.32/ext4-correctly-calculate-number-of-blocks-for-fiemap.patch b/queue-2.6.32/ext4-correctly-calculate-number-of-blocks-for-fiemap.patch new file mode 100644 index 00000000000..43e028a0587 --- /dev/null +++ b/queue-2.6.32/ext4-correctly-calculate-number-of-blocks-for-fiemap.patch @@ -0,0 +1,52 @@ +From aca92ff6f57c000d1b4523e383c8bd6b8269b8b1 Mon Sep 17 00:00:00 2001 +From: Leonard Michlmayr +Date: Thu, 4 Mar 2010 17:07:28 -0500 +Subject: ext4: correctly calculate number of blocks for fiemap + +From: Leonard Michlmayr + +commit aca92ff6f57c000d1b4523e383c8bd6b8269b8b1 upstream. + +ext4_fiemap() rounds the length of the requested range down to +blocksize, which is is not the true number of blocks that cover the +requested region. This problem is especially impressive if the user +requests only the first byte of a file: not a single extent will be +reported. + +We fix this by calculating the last block of the region and then +subtract to find the number of blocks in the extents. + +Signed-off-by: Leonard Michlmayr +Signed-off-by: "Theodore Ts'o" +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -3711,7 +3711,6 @@ int ext4_fiemap(struct inode *inode, str + __u64 start, __u64 len) + { + ext4_lblk_t start_blk; +- ext4_lblk_t len_blks; + int error = 0; + + /* fallback to generic here if not in extents fmt */ +@@ -3725,8 +3724,14 @@ int ext4_fiemap(struct inode *inode, str + if (fieinfo->fi_flags & FIEMAP_FLAG_XATTR) { + error = ext4_xattr_fiemap(inode, fieinfo); + } else { ++ ext4_lblk_t len_blks; ++ __u64 last_blk; ++ + start_blk = start >> inode->i_sb->s_blocksize_bits; +- len_blks = len >> inode->i_sb->s_blocksize_bits; ++ last_blk = (start + len - 1) >> inode->i_sb->s_blocksize_bits; ++ if (last_blk >= EXT_MAX_BLOCK) ++ last_blk = EXT_MAX_BLOCK-1; ++ len_blks = ((ext4_lblk_t) last_blk) - start_blk + 1; + + /* + * Walk the extent tree gathering extent information. diff --git a/queue-2.6.32/initramfs-handle-unrecognised-decompressor-when-unpacking.patch b/queue-2.6.32/initramfs-handle-unrecognised-decompressor-when-unpacking.patch new file mode 100644 index 00000000000..8e5674a0054 --- /dev/null +++ b/queue-2.6.32/initramfs-handle-unrecognised-decompressor-when-unpacking.patch @@ -0,0 +1,43 @@ +From df37bd156dcb4f5441beaf5bde444adac974e9a0 Mon Sep 17 00:00:00 2001 +From: Phillip Lougher +Date: Fri, 23 Apr 2010 13:18:11 -0400 +Subject: initramfs: handle unrecognised decompressor when unpacking + +From: Phillip Lougher + +commit df37bd156dcb4f5441beaf5bde444adac974e9a0 upstream. + +The unpack routine fails to handle the decompress_method() returning +unrecognised decompressor (compress_name == NULL). This results in the +routine looping eventually oopsing on an out of bounds memory access. + +Note this bug is usually hidden, only triggering on trailing junk after +one or more correct compressed blocks. The case of the compressed archive +being complete junk is (by accident?) caught by the if (state != Reset) +check because state is initialised to Start, but not updated due to the +decompressor not having been called. Obviously if the junk is trailing a +correctly decompressed buffer, state == Reset from the previous call to +the decompressor. + +Signed-off-by: Phillip Lougher +Reported-by: Aaro Koskinen +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + init/initramfs.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/init/initramfs.c ++++ b/init/initramfs.c +@@ -455,7 +455,8 @@ static char * __init unpack_to_rootfs(ch + compress_name); + message = msg_buf; + } +- } ++ } else ++ error("junk in compressed archive"); + if (state != Reset) + error("junk in compressed archive"); + this_header = saved_offset + my_inptr; diff --git a/queue-2.6.32/jfs-fix-diallocext-error-in-resizing-filesystem.patch b/queue-2.6.32/jfs-fix-diallocext-error-in-resizing-filesystem.patch new file mode 100644 index 00000000000..f940ac6aa00 --- /dev/null +++ b/queue-2.6.32/jfs-fix-diallocext-error-in-resizing-filesystem.patch @@ -0,0 +1,52 @@ +From 2b0b39517d1af5294128dbc2fd7ed39c8effa540 Mon Sep 17 00:00:00 2001 +From: Bill Pemberton +Date: Fri, 16 Apr 2010 08:01:20 -0500 +Subject: jfs: fix diAllocExt error in resizing filesystem + +From: Bill Pemberton + +commit 2b0b39517d1af5294128dbc2fd7ed39c8effa540 upstream. + +Resizing the filesystem would result in an diAllocExt error in some +instances because changes in bmp->db_agsize would not get noticed if +goto extendBmap was called. + +Signed-off-by: Bill Pemberton +Signed-off-by: Dave Kleikamp +Cc: jfs-discussion@lists.sourceforge.net +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/jfs/resize.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/fs/jfs/resize.c ++++ b/fs/jfs/resize.c +@@ -81,6 +81,7 @@ int jfs_extendfs(struct super_block *sb, + struct inode *iplist[1]; + struct jfs_superblock *j_sb, *j_sb2; + uint old_agsize; ++ int agsizechanged = 0; + struct buffer_head *bh, *bh2; + + /* If the volume hasn't grown, get out now */ +@@ -333,6 +334,9 @@ int jfs_extendfs(struct super_block *sb, + */ + if ((rc = dbExtendFS(ipbmap, XAddress, nblocks))) + goto error_out; ++ ++ agsizechanged |= (bmp->db_agsize != old_agsize); ++ + /* + * the map now has extended to cover additional nblocks: + * dn_mapsize = oldMapsize + nblocks; +@@ -432,7 +436,7 @@ int jfs_extendfs(struct super_block *sb, + * will correctly identify the new ag); + */ + /* if new AG size the same as old AG size, done! */ +- if (bmp->db_agsize != old_agsize) { ++ if (agsizechanged) { + if ((rc = diExtendFS(ipimap, ipbmap))) + goto error_out; + diff --git a/queue-2.6.32/libata-fix-accesses-at-lba28-boundary-old-bug-but-nasty-v2.patch b/queue-2.6.32/libata-fix-accesses-at-lba28-boundary-old-bug-but-nasty-v2.patch new file mode 100644 index 00000000000..b3d7c7c77cd --- /dev/null +++ b/queue-2.6.32/libata-fix-accesses-at-lba28-boundary-old-bug-but-nasty-v2.patch @@ -0,0 +1,39 @@ +From 45c4d015a92f72ec47acd0c7557abdc0c8a6499d Mon Sep 17 00:00:00 2001 +From: Mark Lord +Date: Wed, 7 Apr 2010 13:52:08 -0400 +Subject: libata: Fix accesses at LBA28 boundary (old bug, but nasty) (v2) + +From: Mark Lord + +commit 45c4d015a92f72ec47acd0c7557abdc0c8a6499d upstream. + +Most drives from Seagate, Hitachi, and possibly other brands, +do not allow LBA28 access to sector number 0x0fffffff (2^28 - 1). +So instead use LBA48 for such accesses. + +This bug could bite a lot of systems, especially when the user has +taken care to align partitions to 4KB boundaries. On misaligned systems, +it is less likely to be encountered, since a 4KB read would end at +0x10000000 rather than at 0x0fffffff. + +Signed-off-by: Mark Lord +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/ata.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/linux/ata.h ++++ b/include/linux/ata.h +@@ -1000,8 +1000,8 @@ static inline int ata_ok(u8 status) + + static inline int lba_28_ok(u64 block, u32 n_block) + { +- /* check the ending block number */ +- return ((block + n_block) < ((u64)1 << 28)) && (n_block <= 256); ++ /* check the ending block number: must be LESS THAN 0x0fffffff */ ++ return ((block + n_block) < ((1 << 28) - 1)) && (n_block <= 256); + } + + static inline int lba_48_ok(u64 block, u32 n_block) diff --git a/queue-2.6.32/p54pci-rx-frame-length-check.patch b/queue-2.6.32/p54pci-rx-frame-length-check.patch new file mode 100644 index 00000000000..6bc763b4023 --- /dev/null +++ b/queue-2.6.32/p54pci-rx-frame-length-check.patch @@ -0,0 +1,52 @@ +From f5300e04df78feae8107c1846dd3a9e27c071b2f Mon Sep 17 00:00:00 2001 +From: Christian Lamparter +Date: Mon, 18 Jan 2010 00:07:38 +0100 +Subject: p54pci: rx frame length check + +From: Christian Lamparter + +commit f5300e04df78feae8107c1846dd3a9e27c071b2f upstream. + +A long time ago, a user reported several crashes due to +data corruptions which are likely the result of a +not-100%-supported, or faulty? PCI bridge. +( http://patchwork.kernel.org/patch/53004/ ) + +This patch fixes entry #1. +"1. p54p_check_rx_ring - skb_over_panic: Under a ping flood +or just left running for a bit would panic with a skb_over_panic." +As described in the mail: The invalid frame length causes +skb_put to bailout and trigger a crash. + +Note: +Simply dropping the frame is problematic, because if its content +contains a tx feedback we would lose some portion of the device +memory space.... And the driver/mac80211 should handle all other +invalid data. + +Reported-by: Quintin Pitts +Signed-off-by: Christian Lamparter +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/p54/p54pci.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/net/wireless/p54/p54pci.c ++++ b/drivers/net/wireless/p54/p54pci.c +@@ -205,6 +205,14 @@ static void p54p_check_rx_ring(struct ie + i %= ring_limit; + continue; + } ++ ++ if (unlikely(len > priv->common.rx_mtu)) { ++ if (net_ratelimit()) ++ dev_err(&priv->pdev->dev, "rx'd frame size " ++ "exceeds length threshold.\n"); ++ ++ len = priv->common.rx_mtu; ++ } + skb_put(skb, len); + + if (p54_rx(dev, skb)) { diff --git a/queue-2.6.32/pci-ensure-we-re-enable-devices-on-resume.patch b/queue-2.6.32/pci-ensure-we-re-enable-devices-on-resume.patch new file mode 100644 index 00000000000..1ee8da7fa6c --- /dev/null +++ b/queue-2.6.32/pci-ensure-we-re-enable-devices-on-resume.patch @@ -0,0 +1,45 @@ +From cc2893b6af5265baa1d68b17b136cffca9e40cfa Mon Sep 17 00:00:00 2001 +From: Matthew Garrett +Date: Thu, 22 Apr 2010 09:30:51 -0400 +Subject: PCI: Ensure we re-enable devices on resume + +From: Matthew Garrett + +commit cc2893b6af5265baa1d68b17b136cffca9e40cfa upstream. + +If the firmware puts a device back into D0 state at resume time, we'll +update its state in resume_noirq and thus skip the platform resume code. +Calling that code twice should be safe and we ought to avoid getting to +that point anyway, so remove the check and also allow the platform pci +code to be called for D0. + +Fixes USB not being powered after resume on recent Lenovo machines. + +Acked-by: Alex Chiang +Acked-by: Rafael J. Wysocki +Signed-off-by: Matthew Garrett +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -679,7 +679,7 @@ static void __pci_start_power_transition(struct pci_dev *dev, pci_power_t state) + */ + int __pci_complete_power_transition(struct pci_dev *dev, pci_power_t state) + { +- return state > PCI_D0 ? ++ return state >= PCI_D0 ? + pci_platform_power_transition(dev, state) : -EINVAL; + } + EXPORT_SYMBOL_GPL(__pci_complete_power_transition); +@@ -716,10 +716,6 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t state) + */ + return 0; + +- /* Check if we're already there */ +- if (dev->current_state == state) +- return 0; +- + __pci_start_power_transition(dev, state); + + /* This device is quirked not to be put into D3, so diff --git a/queue-2.6.32/series b/queue-2.6.32/series index 021953ed9fd..0e80b9e7805 100644 --- a/queue-2.6.32/series +++ b/queue-2.6.32/series @@ -56,3 +56,14 @@ alsa-hda-fix-max-pcm-level-to-0-db-for-fujitsu-siemens-laptops-using-cx20549-ven alsa-hda-fix-0-db-for-packard-bell-models-using-conexant-cx20549-venice.patch alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-pro-t130-15f.patch alsa-hda-use-olpc-xo-1_5-quirk-for-toshiba-satellite-p500-pspgsc-01800t.patch +libata-fix-accesses-at-lba28-boundary-old-bug-but-nasty-v2.patch +ext4-correctly-calculate-number-of-blocks-for-fiemap.patch +initramfs-handle-unrecognised-decompressor-when-unpacking.patch +drm-i915-fix-tiling-limits-for-i915-class-hw-v2.patch +cred-fix-a-race-in-creds_are_invalid-in-credentials-debugging.patch +jfs-fix-diallocext-error-in-resizing-filesystem.patch +acpi-introduce-kernel-parameter-acpi_sleep-sci_force_enable.patch +p54pci-rx-frame-length-check.patch +drivers-net-wireless-p54-txrx.c-fix-off-by-one-error.patch +dccp_probe-fix-module-load-dependencies-between-dccp-and-dccp_probe.patch +pci-ensure-we-re-enable-devices-on-resume.patch -- 2.47.3