--- /dev/null
+From d7f0eea9e431e1b8b0742a74db1a9490730b2a25 Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Wed, 30 Dec 2009 15:36:42 +0800
+Subject: ACPI: introduce kernel parameter acpi_sleep=sci_force_enable
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+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 <rui.zhang@intel.com>
+Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 {
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-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),
{}
+ };
--- /dev/null
+From e134d200d57d43b171dcb0b55c178a1a0c7db14a Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 21 Apr 2010 10:28:25 +0100
+Subject: CRED: Fix a race in creds_are_invalid() in credentials debugging
+
+From: David Howells <dhowells@redhat.com>
+
+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:[<ffffffff81049889>] [<ffffffff81049889>] __invalid_creds+0x4e/0x52
+ ...
+ Call Trace:
+ [<ffffffff8104a37b>] 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 <roland@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: James Morris <jmorris@namei.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
--- /dev/null
+From 38ff3e6bb987ec583268da8eb22628293095d43b Mon Sep 17 00:00:00 2001
+From: Neil Horman <nhorman@tuxdriver.com>
+Date: Fri, 15 Jan 2010 01:40:55 -0800
+Subject: dccp_probe: Fix module load dependencies between dccp and dccp_probe
+
+From: Neil Horman <nhorman@tuxdriver.com>
+
+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 <nhorman@tuxdriver.com>
+Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: maximilian attems <max@stro.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+
--- /dev/null
+From 088ea189c4c75cdf211146faa4b341a0f7476be6 Mon Sep 17 00:00:00 2001
+From: Darren Jenkins <darrenrjenkins@gmail.com>
+Date: Wed, 17 Feb 2010 23:40:15 +1100
+Subject: drivers/net/wireless/p54/txrx.c Fix off by one error
+
+From: Darren Jenkins <darrenrjenkins@gmail.com>
+
+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 <darrenrjenkins@gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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];
--- /dev/null
+From c36a2a6de59e4a141a68b7575de837d3b0bd96b3 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sat, 17 Apr 2010 15:12:03 +0200
+Subject: drm/i915: fix tiling limits for i915 class hw v2
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+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 <daniel.vetter@ffwll.ch>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449
+Tested-by: Alexander Lam <lambchop468@gmail.com>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
+
--- /dev/null
+From aca92ff6f57c000d1b4523e383c8bd6b8269b8b1 Mon Sep 17 00:00:00 2001
+From: Leonard Michlmayr <leonard.michlmayr@gmail.com>
+Date: Thu, 4 Mar 2010 17:07:28 -0500
+Subject: ext4: correctly calculate number of blocks for fiemap
+
+From: Leonard Michlmayr <leonard.michlmayr@gmail.com>
+
+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 <leonard.michlmayr@gmail.com>
+Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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.
--- /dev/null
+From df37bd156dcb4f5441beaf5bde444adac974e9a0 Mon Sep 17 00:00:00 2001
+From: Phillip Lougher <phillip@lougher.demon.co.uk>
+Date: Fri, 23 Apr 2010 13:18:11 -0400
+Subject: initramfs: handle unrecognised decompressor when unpacking
+
+From: Phillip Lougher <phillip@lougher.demon.co.uk>
+
+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 <phillip@lougher.demon.co.uk>
+Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+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>
+
+---
+ 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;
--- /dev/null
+From 2b0b39517d1af5294128dbc2fd7ed39c8effa540 Mon Sep 17 00:00:00 2001
+From: Bill Pemberton <wfp5p@virginia.edu>
+Date: Fri, 16 Apr 2010 08:01:20 -0500
+Subject: jfs: fix diAllocExt error in resizing filesystem
+
+From: Bill Pemberton <wfp5p@virginia.edu>
+
+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 <wfp5p@virginia.edu>
+Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
+Cc: jfs-discussion@lists.sourceforge.net
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+
--- /dev/null
+From 45c4d015a92f72ec47acd0c7557abdc0c8a6499d Mon Sep 17 00:00:00 2001
+From: Mark Lord <kernel@teksavvy.com>
+Date: Wed, 7 Apr 2010 13:52:08 -0400
+Subject: libata: Fix accesses at LBA28 boundary (old bug, but nasty) (v2)
+
+From: Mark Lord <kernel@teksavvy.com>
+
+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 <mlord@pobox.com>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
--- /dev/null
+From f5300e04df78feae8107c1846dd3a9e27c071b2f Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunkeey@googlemail.com>
+Date: Mon, 18 Jan 2010 00:07:38 +0100
+Subject: p54pci: rx frame length check
+
+From: Christian Lamparter <chunkeey@googlemail.com>
+
+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 <geek4linux@gmail.com>
+Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)) {
--- /dev/null
+From cc2893b6af5265baa1d68b17b136cffca9e40cfa Mon Sep 17 00:00:00 2001
+From: Matthew Garrett <mjg@redhat.com>
+Date: Thu, 22 Apr 2010 09:30:51 -0400
+Subject: PCI: Ensure we re-enable devices on resume
+
+From: Matthew Garrett <mjg@redhat.com>
+
+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 <achiang@canonical.com>
+Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+--- 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
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
