--- /dev/null
+From cebbert@redhat.com Tue Nov 4 15:04:26 2008
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+Date: Fri, 31 Oct 2008 17:27:16 -0400
+Subject: ACPI: Clear WAK_STS on resume
+To: stable@kernel.org
+Cc: Len Brown <len.brown@intel.com>
+Message-ID: <20081031172716.10a2080c@redhat.com>
+
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+
+Subject: ACPI: Clear WAK_STS on resume
+
+commit a68823ee5285e65b51ceb96f8b13a5b4f99a6888 upstream.
+
+ACPI: Clear WAK_STS on resume
+
+The leading other brand OS appears to clear the WAK_STS flag on resume.
+When rebooted, certain BIOSes assume that the system is actually
+resuming if it's still set and so fail to reboot correctly. Make sure
+that it's cleared at resume time.
+
+Comment clarified as suggested by Bob Moore
+
+http://bugzilla.kernel.org/show_bug.cgi?id=11634
+
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+Signed-off-by: Andi Kleen <ak@linux.intel.com>
+Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/hardware/hwsleep.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/acpi/hardware/hwsleep.c
++++ b/drivers/acpi/hardware/hwsleep.c
+@@ -612,6 +612,13 @@ acpi_status acpi_leave_sleep_state(u8 sl
+ }
+ /* TBD: _WAK "sometimes" returns stuff - do we want to look at it? */
+
++ /*
++ * Some BIOSes assume that WAK_STS will be cleared on resume and use
++ * it to determine whether the system is rebooting or resuming. Clear
++ * it for compatibility.
++ */
++ acpi_set_register(ACPI_BITREG_WAKE_STATUS, 1);
++
+ acpi_gbl_system_awake_and_running = TRUE;
+
+ /* Enable power button */
--- /dev/null
+From cebbert@redhat.com Tue Nov 4 15:02:34 2008
+From: Zhao Yakui <yakui.zhao@intel.com>
+Date: Fri, 31 Oct 2008 17:25:45 -0400
+Subject: ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
+To: stable@kernel.org
+Cc: Len Brown <len.brown@intel.com>
+Message-ID: <20081031172545.0a1486d9@redhat.com>
+
+From: Zhao Yakui <yakui.zhao@intel.com>
+
+Subject: ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
+
+commit 8fd145917fb62368a9b80db59562c20576238f5a upstream
+
+ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
+
+According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
+whether the ACPI reboot mechanism is supported.
+
+However, some boxes have this bit clear, have a valid
+ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
+mechanism that works for them after S3.
+
+This suggests that other operating systems may not be checking
+the RESET_REG_SUP bit, and are using other means to decide
+whether to use the ACPI reboot mechanism or not.
+
+Here we stop checking RESET_REG_SUP.
+Instead, When acpi reboot is requested,
+only the reset_register is checked. If the following
+conditions are met, it indicates that the reset register is supported.
+ a. reset_register is not zero
+ b. the access width is eight
+ c. the bit_offset is zero
+
+http://bugzilla.kernel.org/show_bug.cgi?id=7299
+http://bugzilla.kernel.org/show_bug.cgi?id=1148
+
+Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/reboot.c | 25 ++++++++++++++++++++++---
+ 1 file changed, 22 insertions(+), 3 deletions(-)
+
+--- a/drivers/acpi/reboot.c
++++ b/drivers/acpi/reboot.c
+@@ -15,9 +15,28 @@ void acpi_reboot(void)
+
+ rr = &acpi_gbl_FADT.reset_register;
+
+- /* Is the reset register supported? */
+- if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
+- rr->bit_width != 8 || rr->bit_offset != 0)
++ /*
++ * Is the ACPI reset register supported?
++ *
++ * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
++ * whether the ACPI reset mechanism is supported.
++ *
++ * However, some boxes have this bit clear, yet a valid
++ * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
++ * mechanism that works for them after S3.
++ *
++ * This suggests that other operating systems may not be checking
++ * the RESET_REG_SUP bit, and are using other means to decide
++ * whether to use the ACPI reboot mechanism or not.
++ *
++ * So when acpi reboot is requested,
++ * only the reset_register is checked. If the following
++ * conditions are met, it indicates that the reset register is supported.
++ * a. reset_register is not zero
++ * b. the access width is eight
++ * c. the bit_offset is zero
++ */
++ if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0)
+ return;
+
+ reset_value = acpi_gbl_FADT.reset_value;
--- /dev/null
+From ce39a800ea87c655de49af021c8b20ee323cb40d Mon Sep 17 00:00:00 2001
+From: Andy Gospodarek <andy@greyhouse.net>
+Date: Thu, 30 Oct 2008 17:41:16 -0700
+Subject: bonding: fix panic when taking bond interface down before removing module
+
+From: Andy Gospodarek <andy@greyhouse.net>
+
+commit ce39a800ea87c655de49af021c8b20ee323cb40d upstream.
+
+A panic was discovered with bonding when using mode 5 or 6 and trying to
+remove the slaves from the bond after the interface was taken down.
+When calling 'ifconfig bond0 down' the following happens:
+
+ bond_close()
+ bond_alb_deinitialize()
+ tlb_deinitialize()
+ kfree(bond_info->tx_hashtbl)
+ bond_info->tx_hashtbl = NULL
+
+Unfortunately if there are still slaves in the bond, when removing the
+module the following happens:
+
+ bonding_exit()
+ bond_free_all()
+ bond_release_all()
+ bond_alb_deinit_slave()
+ tlb_clear_slave()
+ tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
+ u32 next_index = tx_hash_table[index].next
+
+As you might guess we panic when trying to access a few entries into the
+table that no longer exists.
+
+I experimented with several options (like moving the calls to
+tlb_deinitialize somewhere else), but it really makes the most sense to
+be part of the bond_close routine. It also didn't seem logical move
+tlb_clear_slave around too much, so the simplest option seems to add a
+check in tlb_clear_slave to make sure we haven't already wiped the
+tx_hashtbl away before searching for all the non-existent hash-table
+entries that used to point to the slave as the output interface.
+
+Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
+Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/bonding/bond_alb.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/bonding/bond_alb.c
++++ b/drivers/net/bonding/bond_alb.c
+@@ -167,11 +167,14 @@ static void tlb_clear_slave(struct bondi
+ /* clear slave from tx_hashtbl */
+ tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl;
+
+- index = SLAVE_TLB_INFO(slave).head;
+- while (index != TLB_NULL_INDEX) {
+- u32 next_index = tx_hash_table[index].next;
+- tlb_init_table_entry(&tx_hash_table[index], save_load);
+- index = next_index;
++ /* skip this if we've already freed the tx hash table */
++ if (tx_hash_table) {
++ index = SLAVE_TLB_INFO(slave).head;
++ while (index != TLB_NULL_INDEX) {
++ u32 next_index = tx_hash_table[index].next;
++ tlb_init_table_entry(&tx_hash_table[index], save_load);
++ index = next_index;
++ }
+ }
+
+ tlb_init_slave(slave);
--- /dev/null
+From 3318a386e4ca68c76e0294363d29bdc46fcad670 Mon Sep 17 00:00:00 2001
+From: Serge Hallyn <serue@us.ibm.com>
+Date: Thu, 30 Oct 2008 11:52:23 -0500
+Subject: file caps: always start with clear bprm->caps_*
+
+From: Serge Hallyn <serue@us.ibm.com>
+
+commit 3318a386e4ca68c76e0294363d29bdc46fcad670 upstream
+
+While Linux doesn't honor setuid on scripts. However, it mistakenly
+behaves differently for file capabilities.
+
+This patch fixes that behavior by making sure that get_file_caps()
+begins with empty bprm->caps_*. That way when a script is loaded,
+its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(),
+but they will be cleared again when binfmt_elf calls prepare_binprm()
+next to read the interpreter's file capabilities.
+
+Signed-off-by: Serge Hallyn <serue@us.ibm.com>
+Acked-by: David Howells <dhowells@redhat.com>
+Acked-by: Andrew G. Morgan <morgan@kernel.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ security/commoncap.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/security/commoncap.c
++++ b/security/commoncap.c
+@@ -279,10 +279,10 @@ static int get_file_caps(struct linux_bi
+ struct vfs_cap_data vcaps;
+ struct inode *inode;
+
+- if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
+- bprm_clear_caps(bprm);
++ bprm_clear_caps(bprm);
++
++ if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID)
+ return 0;
+- }
+
+ dentry = dget(bprm->file->f_dentry);
+ inode = dentry->d_inode;
--- /dev/null
+From 649f1ee6c705aab644035a7998d7b574193a598a Mon Sep 17 00:00:00 2001
+From: Eric Sesterhenn <snakebyte@gmx.de>
+Date: Wed, 15 Oct 2008 22:04:10 -0700
+Subject: hfsplus: check read_mapping_page() return value
+
+From: Eric Sesterhenn <snakebyte@gmx.de>
+
+While testing more corrupted images with hfsplus, i came across
+one which triggered the following bug:
+
+[15840.675016] BUG: unable to handle kernel paging request at fffffffb
+[15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56
+[15840.675016] *pde = 00008067 *pte = 00000000
+[15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
+[15840.675016] Modules linked in:
+[15840.675016]
+[15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #29)
+[15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0
+[15840.675016] EIP is at kmap+0x15/0x56
+[15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0
+[15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94
+[15840.675016] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
+[15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000)
+[15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb
+[15840.675016] cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960
+[15840.675016] 000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000
+[15840.675016] Call Trace:
+[15840.675016] [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3
+[15840.675016] [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db
+[15840.675016] [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d
+[15840.675016] [<c06adde4>] ? sub_preempt_count+0x9d/0xab
+[15840.675016] [<c019ece6>] ? __block_prepare_write+0x147/0x311
+[15840.675016] [<c0161934>] ? __grab_cache_page+0x52/0x73
+[15840.675016] [<c019ef4f>] ? block_write_begin+0x79/0xd5
+[15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
+[15840.675016] [<c019f22a>] ? cont_write_begin+0x27f/0x2af
+[15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
+[15840.675016] [<c0139ebe>] ? tick_program_event+0x28/0x4c
+[15840.675016] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[15840.675016] [<c022b723>] ? hfsplus_write_begin+0x2d/0x32
+[15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
+[15840.675016] [<c0161988>] ? pagecache_write_begin+0x33/0x107
+[15840.675016] [<c01879e5>] ? __page_symlink+0x3c/0xae
+[15840.675016] [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137
+[15840.675016] [<c0187a70>] ? page_symlink+0x19/0x1e
+[15840.675016] [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6
+[15840.675016] [<c01886a9>] ? vfs_symlink+0x99/0x101
+[15840.675016] [<c018a2f6>] ? sys_symlinkat+0x6b/0xad
+[15840.675016] [<c018a348>] ? sys_symlink+0x10/0x12
+[15840.675016] [<c01038bd>] ? sysenter_do_call+0x12/0x31
+[15840.675016] =======================
+[15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
+[15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94
+[15840.675016] ---[ end trace 4fea40dad6b70e5f ]---
+
+This happens because the return value of read_mapping_page() is passed on
+to kmap unchecked. The bug is triggered after the first
+read_mapping_page() in hfsplus_block_allocate(), this patch fixes all
+three usages in this functions but leaves the ones further down in the
+file unchanged.
+
+Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
+Cc: Roman Zippel <zippel@linux-m68k.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/hfsplus/bitmap.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/fs/hfsplus/bitmap.c
++++ b/fs/hfsplus/bitmap.c
+@@ -32,6 +32,10 @@ int hfsplus_block_allocate(struct super_
+ mutex_lock(&HFSPLUS_SB(sb).alloc_file->i_mutex);
+ mapping = HFSPLUS_SB(sb).alloc_file->i_mapping;
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS, NULL);
++ if (IS_ERR(page)) {
++ start = size;
++ goto out;
++ }
+ pptr = kmap(page);
+ curr = pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32;
+ i = offset % 32;
+@@ -73,6 +77,10 @@ int hfsplus_block_allocate(struct super_
+ break;
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS,
+ NULL);
++ if (IS_ERR(page)) {
++ start = size;
++ goto out;
++ }
+ curr = pptr = kmap(page);
+ if ((size ^ offset) / PAGE_CACHE_BITS)
+ end = pptr + PAGE_CACHE_BITS / 32;
+@@ -120,6 +128,10 @@ found:
+ offset += PAGE_CACHE_BITS;
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS,
+ NULL);
++ if (IS_ERR(page)) {
++ start = size;
++ goto out;
++ }
+ pptr = kmap(page);
+ curr = pptr;
+ end = pptr + PAGE_CACHE_BITS / 32;
--- /dev/null
+From efc7ffcb4237f8cb9938909041c4ed38f6e1bf40 Mon Sep 17 00:00:00 2001
+From: Eric Sesterhenn <snakebyte@gmx.de>
+Date: Wed, 15 Oct 2008 22:04:08 -0700
+Subject: hfsplus: fix Buffer overflow with a corrupted image
+
+From: Eric Sesterhenn <snakebyte@gmx.de>
+
+commit efc7ffcb4237f8cb9938909041c4ed38f6e1bf40 upstream
+
+When an hfsplus image gets corrupted it might happen that the catalog
+namelength field gets b0rked. If we mount such an image the memcpy() in
+hfsplus_cat_build_key_uni() writes more than the 255 that fit in the name
+field. Depending on the size of the overwritten data, we either only get
+memory corruption or also trigger an oops like this:
+
+[ 221.628020] BUG: unable to handle kernel paging request at c82b0000
+[ 221.629066] IP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151
+[ 221.629066] *pde = 0ea29163 *pte = 082b0160
+[ 221.629066] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
+[ 221.629066] Modules linked in:
+[ 221.629066]
+[ 221.629066] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #28)
+[ 221.629066] EIP: 0060:[<c022d4b1>] EFLAGS: 00010206 CPU: 0
+[ 221.629066] EIP is at hfsplus_find_cat+0x10d/0x151
+[ 221.629066] EAX: 00000029 EBX: 00016210 ECX: 000042c2 EDX: 00000002
+[ 221.629066] ESI: c82d70ca EDI: c82b0000 EBP: c82d1bcc ESP: c82d199c
+[ 221.629066] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
+[ 221.629066] Process mount (pid: 4845, ti=c82d1000 task=c8224060 task.ti=c82d1000)
+[ 221.629066] Stack: c080b3c4 c82aa8f8 c82d19c2 00016210 c080b3be c82d1bd4 c82aa8f0 00000300
+[ 221.629066] 01000000 750008b1 74006e00 74006900 65006c00 c82d6400 c013bd35 c8224060
+[ 221.629066] 00000036 00000046 c82d19f0 00000082 c8224548 c8224060 00000036 c0d653cc
+[ 221.629066] Call Trace:
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96
+[ 221.629066] [<c01302d2>] ? __kernel_text_address+0x1b/0x27
+[ 221.629066] [<c010487a>] ? dump_trace+0xca/0xd6
+[ 221.629066] [<c0109e32>] ? save_stack_address+0x0/0x2c
+[ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
+[ 221.629066] [<c013b571>] ? save_trace+0x37/0x8d
+[ 221.629066] [<c013b62e>] ? add_lock_to_list+0x67/0x8d
+[ 221.629066] [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
+[ 221.629066] [<c013553d>] ? down+0xc/0x2f
+[ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96
+[ 221.629066] [<c013da5d>] ? mark_held_locks+0x43/0x5a
+[ 221.629066] [<c013dc3a>] ? trace_hardirqs_on+0xb/0xd
+[ 221.629066] [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
+[ 221.629066] [<c06abec8>] ? _spin_unlock_irqrestore+0x42/0x58
+[ 221.629066] [<c013555c>] ? down+0x2b/0x2f
+[ 221.629066] [<c022aa68>] ? hfsplus_iget+0xa0/0x154
+[ 221.629066] [<c022b0b9>] ? hfsplus_fill_super+0x280/0x447
+[ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
+[ 221.629066] [<c041c9e4>] ? string+0x2b/0x74
+[ 221.629066] [<c041cd16>] ? vsnprintf+0x2e9/0x512
+[ 221.629066] [<c010487a>] ? dump_trace+0xca/0xd6
+[ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
+[ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
+[ 221.629066] [<c013b571>] ? save_trace+0x37/0x8d
+[ 221.629066] [<c013b62e>] ? add_lock_to_list+0x67/0x8d
+[ 221.629066] [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
+[ 221.629066] [<c01354d3>] ? up+0xc/0x2f
+[ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
+[ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
+[ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96
+[ 221.629066] [<c041cfb7>] ? snprintf+0x1b/0x1d
+[ 221.629066] [<c01ba466>] ? disk_name+0x25/0x67
+[ 221.629066] [<c0183960>] ? get_sb_bdev+0xcd/0x10b
+[ 221.629066] [<c016ad92>] ? kstrdup+0x2a/0x4c
+[ 221.629066] [<c022a7b3>] ? hfsplus_get_sb+0x13/0x15
+[ 221.629066] [<c022ae39>] ? hfsplus_fill_super+0x0/0x447
+[ 221.629066] [<c0183583>] ? vfs_kern_mount+0x3b/0x76
+[ 221.629066] [<c0183602>] ? do_kern_mount+0x32/0xba
+[ 221.629066] [<c01960d4>] ? do_new_mount+0x46/0x74
+[ 221.629066] [<c0196277>] ? do_mount+0x175/0x193
+[ 221.629066] [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
+[ 221.629066] [<c01663b2>] ? __get_free_pages+0x1e/0x24
+[ 221.629066] [<c06ac07b>] ? lock_kernel+0x19/0x8c
+[ 221.629066] [<c01962e6>] ? sys_mount+0x51/0x9b
+[ 221.629066] [<c01962f9>] ? sys_mount+0x64/0x9b
+[ 221.629066] [<c01038bd>] ? sysenter_do_call+0x12/0x31
+[ 221.629066] =======================
+[ 221.629066] Code: 89 c2 c1 e2 08 c1 e8 08 09 c2 8b 85 e8 fd ff ff 66 89 50 06 89 c7 53 83 c7 08 56 57 68 c4 b3 80 c0 e8 8c 5c ef ff 89 d9 c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
+[ 221.629066] EIP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151 SS:ESP 0068:c82d199c
+[ 221.629066] ---[ end trace e417a1d67f0d0066 ]---
+
+Since hfsplus_cat_build_key_uni() returns void and only has one callsite,
+the check is performed at the callsite.
+
+Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
+Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
+Cc: Roman Zippel <zippel@linux-m68k.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/hfsplus/catalog.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/fs/hfsplus/catalog.c
++++ b/fs/hfsplus/catalog.c
+@@ -168,6 +168,11 @@ int hfsplus_find_cat(struct super_block
+ return -EIO;
+ }
+
++ if (be16_to_cpu(tmp.thread.nodeName.length) > 255) {
++ printk(KERN_ERR "hfs: catalog name length corrupted\n");
++ return -EIO;
++ }
++
+ hfsplus_cat_build_key_uni(fd->search_key, be32_to_cpu(tmp.thread.parentID),
+ &tmp.thread.nodeName);
+ return hfs_brec_find(fd);
--- /dev/null
+From cebbert@redhat.com Tue Nov 4 15:05:47 2008
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+Date: Fri, 31 Oct 2008 17:29:07 -0400
+Subject: Input: atkbd - expand Latitude's force release quirk to other Dells
+To: stable@kernel.org
+Cc: Dmitry Torokhov <dtor@mail.ru>
+Message-ID: <20081031172907.2d3e43a7@redhat.com>
+
+
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+
+commit 61579ba83934d397a4fa2bb7372de9ae112587d5 upstream.
+
+Input: atkbd - expand Latitude's force release quirk to other Dells
+
+Dell laptops fail to send key up events for several of their special
+keys. There's an existing quirk in the kernel to handle this, but it's
+limited to the Latitude range. This patch extends it to cover all
+portable Dells.
+
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/input/keyboard/atkbd.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/input/keyboard/atkbd.c
++++ b/drivers/input/keyboard/atkbd.c
+@@ -834,10 +834,10 @@ static void atkbd_disconnect(struct seri
+ }
+
+ /*
+- * Most special keys (Fn+F?) on Dell Latitudes do not generate release
++ * Most special keys (Fn+F?) on Dell laptops do not generate release
+ * events so we have to do it ourselves.
+ */
+-static void atkbd_latitude_keymap_fixup(struct atkbd *atkbd)
++static void atkbd_dell_laptop_keymap_fixup(struct atkbd *atkbd)
+ {
+ const unsigned int forced_release_keys[] = {
+ 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8f, 0x93,
+@@ -1461,13 +1461,13 @@ static int __init atkbd_setup_fixup(cons
+
+ static struct dmi_system_id atkbd_dmi_quirk_table[] __initdata = {
+ {
+- .ident = "Dell Latitude series",
++ .ident = "Dell Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+- DMI_MATCH(DMI_PRODUCT_NAME, "Latitude"),
++ DMI_MATCH(DMI_CHASSIS_TYPE, "8"), /* Portable */
+ },
+ .callback = atkbd_setup_fixup,
+- .driver_data = atkbd_latitude_keymap_fixup,
++ .driver_data = atkbd_dell_laptop_keymap_fixup,
+ },
+ {
+ .ident = "HP 2133",
--- /dev/null
+From cebbert@redhat.com Tue Nov 4 14:59:23 2008
+From: Ondrej Zary <linux@rainbow-software.org>
+Date: Fri, 31 Oct 2008 17:16:43 -0400
+Subject: libata: Fix LBA48 on pata_it821x RAID volumes.
+To: stable@kernel.org
+Cc: Alan Cox <alan@redhat.com>
+Message-ID: <20081031171643.599fdde2@redhat.com>
+
+From: Ondrej Zary <linux@rainbow-software.org>
+
+Subject: libata: Fix LBA48 on pata_it821x RAID volumes.
+
+commit 054e5f616b5becdc096b793407dc33fe379749ac upstream
+
+libata: Fix LBA48 on pata_it821x RAID volumes.
+
+[http://lkml.org/lkml/2008/10/18/82]
+
+Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
+Acked-by: Alan Cox <alan@redhat.com>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/pata_it821x.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/ata/pata_it821x.c
++++ b/drivers/ata/pata_it821x.c
+@@ -557,9 +557,8 @@ static unsigned int it821x_read_id(struc
+ if (strstr(model_num, "Integrated Technology Express")) {
+ /* Set feature bits the firmware neglects */
+ id[49] |= 0x0300; /* LBA, DMA */
+- id[82] |= 0x0400; /* LBA48 */
+ id[83] &= 0x7FFF;
+- id[83] |= 0x4000; /* Word 83 is valid */
++ id[83] |= 0x4400; /* Word 83 is valid and LBA48 */
+ id[86] |= 0x0400; /* LBA48 on */
+ id[ATA_ID_MAJOR_VER] |= 0x1F;
+ }
acpi-ec-do-transaction-from-interrupt-context.patch
acpi-ec-rename-some-variables.patch
acpi-ec-check-for-ibf-0-periodically-if-not-in-gpe-mode.patch
+libata-fix-lba48-on-pata_it821x-raid-volumes.patch
+acpi-ingore-the-reset_reg_sup-bit-when-using-acpi-reset-mechanism.patch
+acpi-clear-wak_sts-on-resume.patch
+input-atkbd-expand-latitude-s-force-release-quirk-to-other-dells.patch
+hfsplus-fix-buffer-overflow-with-a-corrupted-image.patch
+hfsplus-check-read_mapping_page-return-value.patch
+bonding-fix-panic-when-taking-bond-interface-down-before-removing-module.patch
+file-caps-always-start-with-clear-bprm-caps_.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
