--- /dev/null
+From fc5a9f8841ee87d93376ada5d73117d4d6a373ea Mon Sep 17 00:00:00 2001
+From: Holger Macht <hmacht@suse.de>
+Date: Tue, 20 Jan 2009 12:18:24 +0100
+Subject: ACPI: dock: Don't eval _STA on every show_docked sysfs read
+
+From: Holger Macht <hmacht@suse.de>
+
+commit fc5a9f8841ee87d93376ada5d73117d4d6a373ea upstream.
+
+Some devices trigger a DEVICE_CHECK on every evalutation of _STA. This
+can also be seen in commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db
+(ACPI: dock: avoid check _STA method). If an undock is processed, the
+dock driver sends a uevent and userspace might read the show_docked
+property in sysfs. This causes an evaluation of _STA of the particular
+device which causes the dock driver to immediately dock again.
+
+In any case, evaluation of _STA (show_docked) does not necessarily mean
+that we are docked, so check with the internal device structure.
+
+http://bugzilla.kernel.org/show_bug.cgi?id=12360
+
+Signed-off-by: Holger Macht <hmacht@suse.de>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/acpi/dock.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/dock.c
++++ b/drivers/acpi/dock.c
+@@ -855,10 +855,14 @@ fdd_out:
+ static ssize_t show_docked(struct device *dev,
+ struct device_attribute *attr, char *buf)
+ {
++ struct acpi_device *tmp;
++
+ struct dock_station *dock_station = *((struct dock_station **)
+ dev->platform_data);
+- return snprintf(buf, PAGE_SIZE, "%d\n", dock_present(dock_station));
+
++ if (ACPI_SUCCESS(acpi_bus_get_device(dock_station->handle, &tmp)))
++ return snprintf(buf, PAGE_SIZE, "1\n");
++ return snprintf(buf, PAGE_SIZE, "0\n");
+ }
+ static DEVICE_ATTR(docked, S_IRUGO, show_docked, NULL);
+
--- /dev/null
+From d96f94c604453f87fe24154b87e1e9a3a72511f8 Mon Sep 17 00:00:00 2001
+From: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
+Date: Mon, 2 Feb 2009 11:57:18 -0800
+Subject: ACPI: Enable bit 11 in _PDC to advertise hw coord
+
+From: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
+
+commit d96f94c604453f87fe24154b87e1e9a3a72511f8 upstream.
+
+Bit 11 in intel PDC definitions is meant for OS capability to handle
+hardware coordination of P-states. In Linux we have always supported
+hwardware coordination of P-states. Just let the BIOSes know that we
+support it, by setting this bit.
+
+Some BIOSes use this bit to choose between hardware or software coordination
+and without this change below, BIOSes switch to software coordination, which
+is not very optimal in terms of power consumption and extra wakeups from idle.
+
+Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/acpi/pdc_intel.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/include/acpi/pdc_intel.h
++++ b/include/acpi/pdc_intel.h
+@@ -14,6 +14,7 @@
+ #define ACPI_PDC_SMP_T_SWCOORD (0x0080)
+ #define ACPI_PDC_C_C1_FFH (0x0100)
+ #define ACPI_PDC_C_C2C3_FFH (0x0200)
++#define ACPI_PDC_SMP_P_HWCOORD (0x0800)
+
+ #define ACPI_PDC_EST_CAPABILITY_SMP (ACPI_PDC_SMP_C1PT | \
+ ACPI_PDC_C_C1_HALT | \
+@@ -22,6 +23,7 @@
+ #define ACPI_PDC_EST_CAPABILITY_SWSMP (ACPI_PDC_SMP_C1PT | \
+ ACPI_PDC_C_C1_HALT | \
+ ACPI_PDC_SMP_P_SWCOORD | \
++ ACPI_PDC_SMP_P_HWCOORD | \
+ ACPI_PDC_P_FFH)
+
+ #define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \
--- /dev/null
+From a50ccc6c6623ab0e64f2109881e07c176b2d876f Mon Sep 17 00:00:00 2001
+From: Zhenyu Wang <zhenyu.z.wang@intel.com>
+Date: Mon, 17 Nov 2008 14:39:00 +0800
+Subject: agp/intel: add support for G41 chipset
+
+From: Zhenyu Wang <zhenyu.z.wang@intel.com>
+
+commit a50ccc6c6623ab0e64f2109881e07c176b2d876f upstream.
+
+Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Dave Airlie <airlied@linux.ie>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/agp/intel-agp.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/agp/intel-agp.c
++++ b/drivers/char/agp/intel-agp.c
+@@ -40,6 +40,8 @@
+ #define PCI_DEVICE_ID_INTEL_Q45_IG 0x2E12
+ #define PCI_DEVICE_ID_INTEL_G45_HB 0x2E20
+ #define PCI_DEVICE_ID_INTEL_G45_IG 0x2E22
++#define PCI_DEVICE_ID_INTEL_G41_HB 0x2E30
++#define PCI_DEVICE_ID_INTEL_G41_IG 0x2E32
+
+ /* cover 915 and 945 variants */
+ #define IS_I915 (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_E7221_HB || \
+@@ -63,7 +65,8 @@
+ #define IS_G4X (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_IGD_E_HB || \
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_Q45_HB || \
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G45_HB || \
+- agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_GM45_HB)
++ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_GM45_HB || \
++ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G41_HB)
+
+ extern int agp_memory_reserved;
+
+@@ -1196,6 +1199,7 @@ static void intel_i965_get_gtt_range(int
+ case PCI_DEVICE_ID_INTEL_IGD_E_HB:
+ case PCI_DEVICE_ID_INTEL_Q45_HB:
+ case PCI_DEVICE_ID_INTEL_G45_HB:
++ case PCI_DEVICE_ID_INTEL_G41_HB:
+ *gtt_offset = *gtt_size = MB(2);
+ break;
+ default:
+@@ -2163,6 +2167,8 @@ static const struct intel_driver_descrip
+ "Q45/Q43", NULL, &intel_i965_driver },
+ { PCI_DEVICE_ID_INTEL_G45_HB, PCI_DEVICE_ID_INTEL_G45_IG, 0,
+ "G45/G43", NULL, &intel_i965_driver },
++ { PCI_DEVICE_ID_INTEL_G41_HB, PCI_DEVICE_ID_INTEL_G41_IG, 0,
++ "G41", NULL, &intel_i965_driver },
+ { 0, 0, 0, NULL, NULL, NULL }
+ };
+
+@@ -2360,6 +2366,7 @@ static struct pci_device_id agp_intel_pc
+ ID(PCI_DEVICE_ID_INTEL_IGD_E_HB),
+ ID(PCI_DEVICE_ID_INTEL_Q45_HB),
+ ID(PCI_DEVICE_ID_INTEL_G45_HB),
++ ID(PCI_DEVICE_ID_INTEL_G41_HB),
+ { }
+ };
+
--- /dev/null
+From b854b2ab959e8175d75e01cf8ed452ed2624d0c8 Mon Sep 17 00:00:00 2001
+From: Eric Anholt <eric@anholt.net>
+Date: Mon, 22 Dec 2008 18:56:27 -0800
+Subject: agp/intel: Fix broken ® symbol in device name.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+From: Eric Anholt <eric@anholt.net>
+
+commit b854b2ab959e8175d75e01cf8ed452ed2624d0c8 upstream.
+
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Dave Airlie <airlied@linux.ie>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/agp/intel-agp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/agp/intel-agp.c
++++ b/drivers/char/agp/intel-agp.c
+@@ -2160,7 +2160,7 @@ static const struct intel_driver_descrip
+ { PCI_DEVICE_ID_INTEL_Q33_HB, PCI_DEVICE_ID_INTEL_Q33_IG, 0, "Q33",
+ NULL, &intel_g33_driver },
+ { PCI_DEVICE_ID_INTEL_GM45_HB, PCI_DEVICE_ID_INTEL_GM45_IG, 0,
+- "Mobile Intel? GM45 Express", NULL, &intel_i965_driver },
++ "Mobile Intel® GM45 Express", NULL, &intel_i965_driver },
+ { PCI_DEVICE_ID_INTEL_IGD_E_HB, PCI_DEVICE_ID_INTEL_IGD_E_IG, 0,
+ "Intel Integrated Graphics Device", NULL, &intel_i965_driver },
+ { PCI_DEVICE_ID_INTEL_Q45_HB, PCI_DEVICE_ID_INTEL_Q45_IG, 0,
--- /dev/null
+From ab92661d5d9514647346047f30f67a7f35ffea67 Mon Sep 17 00:00:00 2001
+From: Carsten Otte <cotte@de.ibm.com>
+Date: Wed, 4 Feb 2009 15:12:16 -0800
+Subject: do_wp_page: fix regression with execute in place
+
+From: Carsten Otte <cotte@de.ibm.com>
+
+commit ab92661d5d9514647346047f30f67a7f35ffea67 upstream.
+
+Fix do_wp_page for VM_MIXEDMAP mappings.
+
+In the case where pfn_valid returns 0 for a pfn at the beginning of
+do_wp_page and the mapping is not shared writable, the code branches to
+label `gotten:' with old_page == NULL.
+
+In case the vma is locked (vma->vm_flags & VM_LOCKED), lock_page,
+clear_page_mlock, and unlock_page try to access the old_page.
+
+This patch checks whether old_page is valid before it is dereferenced.
+
+The regression was introduced by "mlock: mlocked pages are unevictable"
+(commit b291f000393f5a0b679012b39d79fbc85c018233).
+
+Signed-off-by: Carsten Otte <cotte@de.ibm.com>
+Cc: Nick Piggin <npiggin@suse.de>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+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>
+
+---
+ mm/memory.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -1881,7 +1881,7 @@ gotten:
+ * Don't let another task, with possibly unlocked vma,
+ * keep the mlocked page.
+ */
+- if (vma->vm_flags & VM_LOCKED) {
++ if ((vma->vm_flags & VM_LOCKED) && old_page) {
+ lock_page(old_page); /* for LRU manipulation */
+ clear_page_mlock(old_page);
+ unlock_page(old_page);
--- /dev/null
+From 15b2bee22a0390d951301b53e83df88d0350c499 Mon Sep 17 00:00:00 2001
+From: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Date: Tue, 27 Jan 2009 16:41:58 -0800
+Subject: e1000: fix bug with shared interrupt during reset
+
+From: Jesse Brandeburg <jesse.brandeburg@intel.com>
+
+commit 15b2bee22a0390d951301b53e83df88d0350c499 upstream.
+
+A nasty bug was found where an MTU change (or anything else that caused a
+reset) could race with the interrupt code. The interrupt code was entered
+by a shared interrupt during the MTU change.
+
+This change prevents the interrupt code from running while the driver is in
+the middle of its reset path.
+
+Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+--- a/drivers/net/e1000/e1000_main.c
++++ b/drivers/net/e1000/e1000_main.c
+@@ -31,7 +31,7 @@
+
+ char e1000_driver_name[] = "e1000";
+ static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver";
+-#define DRV_VERSION "7.3.20-k3-NAPI"
++#define DRV_VERSION "7.3.21-k3-NAPI"
+ const char e1000_driver_version[] = DRV_VERSION;
+ static const char e1000_copyright[] = "Copyright (c) 1999-2006 Intel Corporation.";
+
+@@ -3712,7 +3712,7 @@ static irqreturn_t e1000_intr(int irq, void *data)
+ struct e1000_hw *hw = &adapter->hw;
+ u32 rctl, icr = er32(ICR);
+
+- if (unlikely(!icr))
++ if (unlikely((!icr) || test_bit(__E1000_RESETTING, &adapter->flags)))
+ return IRQ_NONE; /* Not our interrupt */
+
+ /* IMS will not auto-mask if INT_ASSERTED is not set, and if it is
--- /dev/null
+From 4d7155b932b8129c72e2f2714890e20b2a05e0b7 Mon Sep 17 00:00:00 2001
+From: Karsten Keil <kkeil@suse.de>
+Date: Tue, 3 Feb 2009 15:18:01 -0800
+Subject: e1000: Fix PCI enable to honor the need_ioport flag
+
+From: Karsten Keil <kkeil@suse.de>
+
+commit 4d7155b932b8129c72e2f2714890e20b2a05e0b7 upstream.
+
+On machine were no IO ports are assigned the call
+to pci_enable_device() will fail, even if need_ioport
+is false, we need to use pci_enable_device_mem() here.
+
+Signed-off-by: Karsten Keil <kkeil@suse.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/e1000/e1000_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/e1000/e1000_main.c
++++ b/drivers/net/e1000/e1000_main.c
+@@ -921,7 +921,7 @@ static int __devinit e1000_probe(struct
+ err = pci_enable_device(pdev);
+ } else {
+ bars = pci_select_bars(pdev, IORESOURCE_MEM);
+- err = pci_enable_device(pdev);
++ err = pci_enable_device_mem(pdev);
+ }
+ if (err)
+ return err;
--- /dev/null
+From b5f6f26550700445dcc125bbf75b9104e779d353 Mon Sep 17 00:00:00 2001
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+Date: Tue, 20 Jan 2009 16:17:46 +0100
+Subject: eeepc-laptop: Add support for extended hotkeys
+
+From: Matthew Garrett <mjg59@srcf.ucam.org>
+
+commit b5f6f26550700445dcc125bbf75b9104e779d353 upstream.
+
+Newer Eees have extra hotkeys above the function keys. This patch adds support
+for sending them through the input layer.
+
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+Signed-off-by: Corentin Chary <corentincj@iksaif.net>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/misc/eeepc-laptop.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/misc/eeepc-laptop.c
++++ b/drivers/misc/eeepc-laptop.c
+@@ -161,6 +161,10 @@ static struct key_entry eeepc_keymap[] =
+ {KE_KEY, 0x13, KEY_MUTE },
+ {KE_KEY, 0x14, KEY_VOLUMEDOWN },
+ {KE_KEY, 0x15, KEY_VOLUMEUP },
++ {KE_KEY, 0x1a, KEY_COFFEE },
++ {KE_KEY, 0x1b, KEY_ZOOM },
++ {KE_KEY, 0x1c, KEY_PROG2 },
++ {KE_KEY, 0x1d, KEY_PROG3 },
+ {KE_KEY, 0x30, KEY_SWITCHVIDEOMODE },
+ {KE_KEY, 0x31, KEY_SWITCHVIDEOMODE },
+ {KE_KEY, 0x32, KEY_SWITCHVIDEOMODE },
--- /dev/null
+From 7695fb04aca62e2d8a7ca6ede50f6211e1d71e53 Mon Sep 17 00:00:00 2001
+From: Darren Salt <linux@youmustbejoking.demon.co.uk>
+Date: Sat, 7 Feb 2009 01:02:07 -0500
+Subject: eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init
+
+From: Darren Salt <linux@youmustbejoking.demon.co.uk>
+
+commit 7695fb04aca62e2d8a7ca6ede50f6211e1d71e53 upstream.
+
+I got the following oops while changing the backlight brightness during
+startup. When it happens, it prevents use of the hotkeys, Fn-Fx, and the
+lid button.
+
+It's a clear use-before-init, as I verified by testing with an
+appropriately-placed "else printk".
+
+BUG: unable to handle kernel NULL pointer dereference at 00000000
+*pde = 00000000
+Oops: 0002 [#1] PREEMPT SMP
+Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901
+EIP: 0060:[<c0264e68>] [<c0264e68>] eeepc_hotk_notify+26/da
+EFLAGS: 00010246 CPU: 1
+Using defaults from ksymoops -t elf32-i386 -a i386
+EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64
+ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80
+ DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
+ f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f
+ f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80
+ c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091
+Call Trace:
+ [<c02164ac>] ? acpi_ev_notify_dispatch+4c/55
+ [<c02112e6>] ? acpi_os_execute_deferred+1d/25
+ [<c012b62f>] ? run_workqueue+71/f1
+ [<c012bdba>] ? worker_thread+0/bf
+ [<c012be6e>] ? worker_thread+b4/bf
+ [<c012e198>] ? autoremove_wake_function+0/2b
+ [<c012bdba>] ? worker_thread+0/bf
+ [<c012e0c9>] ? kthread+38/5f
+ [<c012e091>] ? kthread+0/5f
+ [<c0103abf>] ? kernel_thread_helper+7/10
+Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42
+e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c
+50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01
+
+Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/misc/eeepc-laptop.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/misc/eeepc-laptop.c
++++ b/drivers/misc/eeepc-laptop.c
+@@ -510,7 +510,8 @@ static int eeepc_hotk_check(void)
+ static void notify_brn(void)
+ {
+ struct backlight_device *bd = eeepc_backlight_device;
+- bd->props.brightness = read_brightness(bd);
++ if (bd)
++ bd->props.brightness = read_brightness(bd);
+ }
+
+ static void eeepc_hotk_notify(acpi_handle handle, u32 event, void *data)
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 11:54:50 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:04:09 +0100 (CET)
+Subject: firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
+To: stable@kernel.org
+Message-ID: <tkrat.f31c98dfaa7ba10a@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream.
+
+Camcorders have a tendency to fail read requests to their config ROM and
+write request to their FCP command register with ack_busy_X. This has
+become a problem with newer kernels and especially Panasonic camcorders,
+causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently
+logs "send oops"; kino reports loss of AV/C control. I suspect that
+lower CPU scheduling latencies in newer kernels made this issue more
+prominent now.
+
+According to
+https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
+this can be fixed by configuring the FireWire controller for more
+hardware retries for request transmission; these retries are evidently
+more successful than libavc1394's own retry loop (typically 3 tries on
+top of hardware retries).
+
+Presumably the same issue has been reported at
+https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
+https://bugzilla.redhat.com/show_bug.cgi?id=477279 .
+
+In a quick test with a JVC camcorder (which didn't malfunction like the
+reported camcorders), this change decreased the number of ack_busy_X
+from 16 in three runs of dvgrab to 4 in three runs of the same capture
+duration.
+
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-ohci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/firewire/fw-ohci.c
++++ b/drivers/firewire/fw-ohci.c
+@@ -226,7 +226,7 @@ static inline struct fw_ohci *fw_ohci(st
+ #define CONTEXT_DEAD 0x0800
+ #define CONTEXT_ACTIVE 0x0400
+
+-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2
++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf
+ #define OHCI1394_MAX_AT_RESP_RETRIES 0x2
+ #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8
+
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 11:56:04 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:05:25 +0100 (CET)
+Subject: firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
+To: stable@kernel.org
+Message-ID: <tkrat.1496b1b3325887a7@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 upstream.
+
+According to https://bugs.launchpad.net/bugs/294391
+ - 3rd generation iPods need the "fix capacity" workaround after all
+ (apparently they crash after the last sector was accessed),
+ - 2nd generation iPods need the "128 kB maximum request size"
+ workaround.
+
+Alas both iPod generations feature the same model ID in the config ROM,
+hence we can only define a shared quirks list entry for them. Luckily
+the fix capacity workaround did not show a negative effect in Jarod's
+tests with 2nd gen. iPod.
+
+A side note: Apple computers in target mode (or at least an x86 Mac
+mini) don't have firmware_version and model_id, hence none of the iPod
+quirks list entries is active for them.
+
+Tested-by: Jarod Wilson <jarod@redhat.com>
+Acked-by: Jarod Wilson <jarod@redhat.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-sbp2.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/firewire/fw-sbp2.c
++++ b/drivers/firewire/fw-sbp2.c
+@@ -357,15 +357,17 @@ static const struct {
+ .model = ~0,
+ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS,
+ },
+-
+ /*
+- * There are iPods (2nd gen, 3rd gen) with model_id == 0, but
+- * these iPods do not feature the read_capacity bug according
+- * to one report. Read_capacity behaviour as well as model_id
+- * could change due to Apple-supplied firmware updates though.
++ * iPod 2nd generation: needs 128k max transfer size workaround
++ * iPod 3rd generation: needs fix capacity workaround
+ */
+-
+- /* iPod 4th generation. */ {
++ {
++ .firmware_revision = 0x0a2700,
++ .model = 0x000000,
++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS |
++ SBP2_WORKAROUND_FIX_CAPACITY,
++ },
++ /* iPod 4th generation */ {
+ .firmware_revision = 0x0a2700,
+ .model = 0x000021,
+ .workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 11:55:20 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:04:45 +0100 (CET)
+Subject: firewire: sbp2: fix DMA mapping leak on the failure path
+To: stable@kernel.org
+Message-ID: <tkrat.cd65a790824b8ca8@s5r6.in-berlin.de>
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 5e2125677fd72d36396cc537466e07ffcbbd4b2b upstream.
+
+Reported-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
+who also provided a first version of the fix.
+
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/firewire/fw-sbp2.c | 27 +++++++++++++++++----------
+ 1 file changed, 17 insertions(+), 10 deletions(-)
+
+--- a/drivers/firewire/fw-sbp2.c
++++ b/drivers/firewire/fw-sbp2.c
+@@ -1282,6 +1282,19 @@ static struct fw_driver sbp2_driver = {
+ .id_table = sbp2_id_table,
+ };
+
++static void sbp2_unmap_scatterlist(struct device *card_device,
++ struct sbp2_command_orb *orb)
++{
++ if (scsi_sg_count(orb->cmd))
++ dma_unmap_sg(card_device, scsi_sglist(orb->cmd),
++ scsi_sg_count(orb->cmd),
++ orb->cmd->sc_data_direction);
++
++ if (orb->request.misc & cpu_to_be32(COMMAND_ORB_PAGE_TABLE_PRESENT))
++ dma_unmap_single(card_device, orb->page_table_bus,
++ sizeof(orb->page_table), DMA_TO_DEVICE);
++}
++
+ static unsigned int
+ sbp2_status_to_sense_data(u8 *sbp2_status, u8 *sense_data)
+ {
+@@ -1361,15 +1374,7 @@ complete_command_orb(struct sbp2_orb *ba
+
+ dma_unmap_single(device->card->device, orb->base.request_bus,
+ sizeof(orb->request), DMA_TO_DEVICE);
+-
+- if (scsi_sg_count(orb->cmd) > 0)
+- dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd),
+- scsi_sg_count(orb->cmd),
+- orb->cmd->sc_data_direction);
+-
+- if (orb->page_table_bus != 0)
+- dma_unmap_single(device->card->device, orb->page_table_bus,
+- sizeof(orb->page_table), DMA_TO_DEVICE);
++ sbp2_unmap_scatterlist(device->card->device, orb);
+
+ orb->cmd->result = result;
+ orb->done(orb->cmd);
+@@ -1500,8 +1505,10 @@ static int sbp2_scsi_queuecommand(struct
+ orb->base.request_bus =
+ dma_map_single(device->card->device, &orb->request,
+ sizeof(orb->request), DMA_TO_DEVICE);
+- if (dma_mapping_error(device->card->device, orb->base.request_bus))
++ if (dma_mapping_error(device->card->device, orb->base.request_bus)) {
++ sbp2_unmap_scatterlist(device->card->device, orb);
+ goto out;
++ }
+
+ sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, generation,
+ lu->command_block_agent_address + SBP2_ORB_POINTER);
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 11:54:08 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:03:22 +0100 (CET)
+Subject: ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
+To: stable@kernel.org
+Message-ID: <tkrat.6d48e1780cdff8b4@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 64c634ef83991b390ec0503e61f16efb0ba3c60b upstream.
+
+Camcorders have a tendency to fail read requests to their config ROM and
+write request to their FCP command register with ack_busy_X. This has
+become a problem with newer kernels and especially Panasonic camcorders,
+causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently
+logs "send oops"; kino reports loss of AV/C control. I suspect that
+lower CPU scheduling latencies in newer kernels made this issue more
+prominent now.
+
+According to
+https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
+this can be fixed by configuring the FireWire controller for more
+hardware retries for request transmission; these retries are evidently
+more successful than libavc1394's own retry loop (typically 3 tries on
+top of hardware retries).
+
+Presumably the same issue has been reported at
+https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
+https://bugzilla.redhat.com/show_bug.cgi?id=477279 .
+
+Tested-by: Mathias Beilstein
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ieee1394/ohci1394.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ieee1394/ohci1394.h
++++ b/drivers/ieee1394/ohci1394.h
+@@ -26,7 +26,7 @@
+
+ #define OHCI1394_DRIVER_NAME "ohci1394"
+
+-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2
++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf
+ #define OHCI1394_MAX_AT_RESP_RETRIES 0x2
+ #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8
+ #define OHCI1394_MAX_SELF_ID_ERRORS 16
--- /dev/null
+From stefanr@s5r6.in-berlin.de Sun Feb 8 11:56:31 2009
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sat, 7 Feb 2009 13:06:06 +0100 (CET)
+Subject: ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
+To: stable@kernel.org
+Message-ID: <tkrat.308b3ddd8e79a4c0@s5r6.in-berlin.de>
+Content-Disposition: INLINE
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+Commit 1448d7c6a2ff96d3b52ecae49e2d0f046a097fe0 upstream.
+
+As per https://bugs.launchpad.net/bugs/294391. These got one sample of
+each iPod generation going. However there still occurred I/O stalls
+with the 3rd generation iPod which remain undiagnosed at the time of
+this writing.
+
+Acked-by: Jarod Wilson <jarod@redhat.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ieee1394/sbp2.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/ieee1394/sbp2.c
++++ b/drivers/ieee1394/sbp2.c
+@@ -395,6 +395,16 @@ static const struct {
+ .model_id = SBP2_ROM_VALUE_WILDCARD,
+ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS,
+ },
++ /*
++ * iPod 2nd generation: needs 128k max transfer size workaround
++ * iPod 3rd generation: needs fix capacity workaround
++ */
++ {
++ .firmware_revision = 0x0a2700,
++ .model_id = 0x000000,
++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS |
++ SBP2_WORKAROUND_FIX_CAPACITY,
++ },
+ /* iPod 4th generation */ {
+ .firmware_revision = 0x0a2700,
+ .model_id = 0x000021,
--- /dev/null
+From de01dfadf25bf83cfe3d85c163005c4320532658 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 6 Feb 2009 18:02:46 +1100
+Subject: md: Ensure an md array never has too many devices.
+
+From: NeilBrown <neilb@suse.de>
+
+commit de01dfadf25bf83cfe3d85c163005c4320532658 upstream.
+
+Each different metadata format supported by md supports a
+different maximum number of devices.
+We really should be enforcing this maximum in the kernel, but
+we aren't quite doing that properly.
+
+We currently only enforce it at the 'hot_add' point, which is an
+older interface which is not used by current userspace.
+
+We need to also enforce it at 'add_new_disk' time for active arrays
+and at 'do_md_run' time when starting a new array.
+
+So move the test from 'hot_add' into 'bind_rdev_to_array' which is
+called from both 'hot_add' and 'add_new_disk, and add a new
+test in 'analyse_sbs' which is called from 'do_md_run'.
+
+This bug (or missing feature) has been around "forever" and so
+the patch is suitable for any -stable that is currently maintained.
+
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/md.c | 24 ++++++++++++++----------
+ 1 file changed, 14 insertions(+), 10 deletions(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -1447,6 +1447,11 @@ static int bind_rdev_to_array(mdk_rdev_t
+ if (find_rdev_nr(mddev, rdev->desc_nr))
+ return -EBUSY;
+ }
++ if (mddev->max_disks && rdev->desc_nr >= mddev->max_disks) {
++ printk(KERN_WARNING "md: %s: array is limited to %d devices\n",
++ mdname(mddev), mddev->max_disks);
++ return -EBUSY;
++ }
+ bdevname(rdev->bdev,b);
+ while ( (s=strchr(b, '/')) != NULL)
+ *s = '!';
+@@ -2355,6 +2360,15 @@ static void analyze_sbs(mddev_t * mddev)
+
+ i = 0;
+ rdev_for_each(rdev, tmp, mddev) {
++ if (rdev->desc_nr >= mddev->max_disks ||
++ i > mddev->max_disks) {
++ printk(KERN_WARNING
++ "md: %s: %s: only %d devices permitted\n",
++ mdname(mddev), bdevname(rdev->bdev, b),
++ mddev->max_disks);
++ kick_rdev_from_array(rdev);
++ continue;
++ }
+ if (rdev != freshest)
+ if (super_types[mddev->major_version].
+ validate_super(mddev, rdev)) {
+@@ -4448,13 +4462,6 @@ static int hot_add_disk(mddev_t * mddev,
+ * noticed in interrupt contexts ...
+ */
+
+- if (rdev->desc_nr == mddev->max_disks) {
+- printk(KERN_WARNING "%s: can not hot-add to full array!\n",
+- mdname(mddev));
+- err = -EBUSY;
+- goto abort_unbind_export;
+- }
+-
+ rdev->raid_disk = -1;
+
+ md_update_sb(mddev, 1);
+@@ -4468,9 +4475,6 @@ static int hot_add_disk(mddev_t * mddev,
+ md_new_event(mddev);
+ return 0;
+
+-abort_unbind_export:
+- unbind_rdev_from_array(rdev);
+-
+ abort_export:
+ export_rdev(rdev);
+ return err;
--- /dev/null
+From 852c8bf484a0e17ee27f413ef26e87f522af5607 Mon Sep 17 00:00:00 2001
+From: Andre Noll <maan@systemlinux.org>
+Date: Fri, 6 Feb 2009 15:10:52 +1100
+Subject: md: Fix a bug in linear.c causing which_dev() to return the wrong device.
+
+From: Andre Noll <maan@systemlinux.org>
+
+commit 852c8bf484a0e17ee27f413ef26e87f522af5607 upstream.
+
+ab5bd5cbc8d4b868378d062eed3d4240930fbb86 introduced the following
+bug in linear software raid for large arrays on 32 bit machines:
+
+which_dev() computes the device holding a given sector by shifting
+down the sector number to a 32 bit range, dividing by the array
+spacing and looking up the resulting index in the hash table of
+the array.
+
+Because the computed index might be slightly too small, a loop at
+the end of which_dev() increases the index until the given sector
+actually falls into the range of the device associated with that index.
+
+The changes of the above mentioned commit caused this loop to check
+whether the _index_ rather than the sector number is small enough,
+effectively bypassing the loop and thus possibly returning the wrong
+device.
+
+As reported by Simon Kirby, this leads to errors such as
+
+ linear_make_request: Sector 2340486136 out of bounds on dev sdi: 156301312 sectors, offset 2109870464
+
+Fix this bug by introducing a local variable for the index so that
+the variable containing the passed sector is left unchanged.
+
+Signed-off-by: Andre Noll <maan@systemlinux.org>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/linear.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/linear.c
++++ b/drivers/md/linear.c
+@@ -25,13 +25,13 @@ static inline dev_info_t *which_dev(mdde
+ {
+ dev_info_t *hash;
+ linear_conf_t *conf = mddev_to_conf(mddev);
++ sector_t idx = sector >> conf->sector_shift;
+
+ /*
+ * sector_div(a,b) returns the remainer and sets a to a/b
+ */
+- sector >>= conf->sector_shift;
+- (void)sector_div(sector, conf->spacing);
+- hash = conf->hash_table[sector];
++ (void)sector_div(idx, conf->spacing);
++ hash = conf->hash_table[idx];
+
+ while (sector >= hash->num_sectors + hash->start_sector)
+ hash++;
--- /dev/null
+From 7f9a50a5b89b87f8e754f59ae9968da28be618a5 Mon Sep 17 00:00:00 2001
+From: Rusty Russell <rusty@rustcorp.com.au>
+Date: Sat, 7 Feb 2009 18:15:56 +1030
+Subject: module: remove over-zealous check in __module_get()
+
+From: Rusty Russell <rusty@rustcorp.com.au>
+
+commit 7f9a50a5b89b87f8e754f59ae9968da28be618a5 upstream.
+
+Impact: fix spurious BUG_ON() triggered under load
+
+module_refcount() isn't reliable outside stop_machine(), as demonstrated
+by Karsten Keil <kkeil@suse.de>, networking can trigger it under load
+(an inc on one cpu and dec on another while module_refcount() is tallying
+ can give false results, for example).
+
+Almost noone should be using __module_get, but that's another issue.
+
+Cc: Karsten Keil <kkeil@suse.de>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/linux/module.h | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/include/linux/module.h
++++ b/include/linux/module.h
+@@ -391,7 +391,6 @@ void symbol_put_addr(void *addr);
+ static inline void __module_get(struct module *module)
+ {
+ if (module) {
+- BUG_ON(module_refcount(module) == 0);
+ local_inc(&module->ref[get_cpu()].count);
+ put_cpu();
+ }
--- /dev/null
+From 9be260a646bf76fa418ee519afa10196b3164681 Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@redhat.com>
+Date: Thu, 5 Feb 2009 17:12:39 -0500
+Subject: prevent kprobes from catching spurious page faults
+
+From: Masami Hiramatsu <mhiramat@redhat.com>
+
+commit 9be260a646bf76fa418ee519afa10196b3164681 upstream.
+
+Prevent kprobes from catching spurious faults which will cause infinite
+recursive page-fault and memory corruption by stack overflow.
+
+Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/mm/fault.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/mm/fault.c
++++ b/arch/x86/mm/fault.c
+@@ -601,8 +601,6 @@ void __kprobes do_page_fault(struct pt_r
+
+ si_code = SEGV_MAPERR;
+
+- if (notify_page_fault(regs))
+- return;
+ if (unlikely(kmmio_fault(regs, address)))
+ return;
+
+@@ -632,6 +630,9 @@ void __kprobes do_page_fault(struct pt_r
+ if (spurious_fault(address, error_code))
+ return;
+
++ /* kprobes don't want to hook the spurious faults. */
++ if (notify_page_fault(regs))
++ return;
+ /*
+ * Don't take the mm semaphore here. If we fixup a prefetch
+ * fault we could otherwise deadlock.
+@@ -639,6 +640,9 @@ void __kprobes do_page_fault(struct pt_r
+ goto bad_area_nosemaphore;
+ }
+
++ /* kprobes don't want to hook the spurious faults. */
++ if (notify_page_fault(regs))
++ return;
+
+ /*
+ * It's safe to allow irq's after cr2 has been saved and the
--- /dev/null
+From 60fd760fb9ff7034360bab7137c917c0330628c2 Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Wed, 4 Feb 2009 15:12:06 -0800
+Subject: revert "rlimit: permit setting RLIMIT_NOFILE to RLIM_INFINITY"
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+commit 60fd760fb9ff7034360bab7137c917c0330628c2 upstream.
+
+Revert commit 0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f because it causes
+(arguably poorly designed) existing userspace to spend interminable
+periods closing billions of not-open file descriptors.
+
+We could bring this back, with some sort of opt-in tunable in /proc, which
+defaults to "off".
+
+Peter's alanysis follows:
+
+: I spent several hours trying to get to the bottom of a serious
+: performance issue that appeared on one of our servers after upgrading to
+: 2.6.28. In the end it's what could be considered a userspace bug that
+: was triggered by a change in 2.6.28. Since this might also affect other
+: people I figured I'd at least document what I found here, and maybe we
+: can even do something about it:
+:
+:
+: So, I upgraded some of debian.org's machines to 2.6.28.1 and immediately
+: the team maintaining our ftp archive complained that one of their
+: scripts that previously ran in a few minutes still hadn't even come
+: close to being done after an hour or so. Downgrading to 2.6.27 fixed
+: that.
+:
+: Turns out that script is forking a lot and something in it or python or
+: whereever closes all the file descriptors it doesn't want to pass on.
+: That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and
+: closes them all with a few exceptions.
+:
+: Turns out that takes a long time when your limit -n is now 2^20 (1048576).
+:
+: With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is
+: now a thousand times that.
+:
+: 2.6.28 included a patch titled "rlimit: permit setting RLIMIT_NOFILE to
+: RLIM_INFINITY" (0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f)[1] that
+: allows, as the title implies, to set the limit for number of files to
+: infinity.
+:
+: Closer investigation showed that the broken default ulimit did not apply
+: to "system" processes (like stuff started from init). In the end I
+: could establish that all processes that passed through pam_limit at one
+: point had the bad resource limit.
+:
+: Apparently the pam library in Debian etch (4.0) initializes the limits
+: to some default values when it doesn't have any settings in limit.conf
+: to override them. Turns out that for nofiles this is RLIM_INFINITY.
+: Commenting out "case RLIMIT_NOFILE" in pam_limit.c:267 of our pam
+: package version 0.79-5 fixes that - tho I'm not sure what side effects
+: that has.
+:
+: Debian lenny (the upcoming 5.0 version) doesn't have this issue as it
+: uses a different pam (version).
+
+Reported-by: Peter Palfrader <weasel@debian.org>
+Cc: Adam Tkac <vonsch@gmail.com>
+Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
+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>
+
+---
+ kernel/sys.c | 16 ++++------------
+ 1 file changed, 4 insertions(+), 12 deletions(-)
+
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -1447,22 +1447,14 @@ SYSCALL_DEFINE2(setrlimit, unsigned int,
+ return -EINVAL;
+ if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
+ return -EFAULT;
++ if (new_rlim.rlim_cur > new_rlim.rlim_max)
++ return -EINVAL;
+ old_rlim = current->signal->rlim + resource;
+ if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
+ !capable(CAP_SYS_RESOURCE))
+ return -EPERM;
+-
+- if (resource == RLIMIT_NOFILE) {
+- if (new_rlim.rlim_max == RLIM_INFINITY)
+- new_rlim.rlim_max = sysctl_nr_open;
+- if (new_rlim.rlim_cur == RLIM_INFINITY)
+- new_rlim.rlim_cur = sysctl_nr_open;
+- if (new_rlim.rlim_max > sysctl_nr_open)
+- return -EPERM;
+- }
+-
+- if (new_rlim.rlim_cur > new_rlim.rlim_max)
+- return -EINVAL;
++ if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
++ return -EPERM;
+
+ retval = security_task_setrlimit(resource, &new_rlim);
+ if (retval)
--- /dev/null
+From 60c20fb8c00a2b23308ae4517f145383bc66d291 Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Fri, 2 Jan 2009 13:49:04 +0000
+Subject: serial: RS485 ioctl structure uses __u32 include linux/types.h
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+From: Andy Whitcroft <apw@canonical.com>
+
+commit 60c20fb8c00a2b23308ae4517f145383bc66d291 upstream.
+
+In the commit below a new struct serial_rs485 was introduced for a new
+ioctl:
+
+ commit c26c56c0f40e200e61d1390629c806f6adaffbcc
+ Author: Alan Cox <alan@redhat.com>
+ Date: Mon Oct 13 10:37:48 2008 +0100
+
+ tty: Cris has a nice RS485 ioctl so we should steal it
+
+This structure uses the __u32 types for some of its members, which leads
+to the following compile error:
+
+ $ cc -I.../include -c X.c
+ In file included from X.c:2: .../include/linux/serial.h:185:
+ error: expected specifier-qualifier-list before ‘__u32’
+ $
+
+It seems that these types are appropriate for this structure as it is
+to be exposed to userspace. These types are available via linux/types.h
+so move the include of that outside the __KERNEL__ section.
+
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Alan Cox <alan@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Matthew Burgess <matthew@linuxfromscratch.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ include/linux/serial.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/linux/serial.h
++++ b/include/linux/serial.h
+@@ -10,8 +10,9 @@
+ #ifndef _LINUX_SERIAL_H
+ #define _LINUX_SERIAL_H
+
+-#ifdef __KERNEL__
+ #include <linux/types.h>
++
++#ifdef __KERNEL__
+ #include <asm/page.h>
+
+ /*
--- /dev/null
+sgi-xp-fix-writing-past-the-end-of-kzalloc-d-space.patch
+do_wp_page-fix-regression-with-execute-in-place.patch
+wait-prevent-exclusive-waiter-starvation.patch
+shm-fix-shmctl-lockup-with-config_shmem.patch
+revert-rlimit-permit-setting-rlimit_nofile-to-rlim_infinity.patch
+prevent-kprobes-from-catching-spurious-page-faults.patch
+sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch
+md-ensure-an-md-array-never-has-too-many-devices.patch
+md-fix-a-bug-in-linear.c-causing-which_dev-to-return-the-wrong-device.patch
+acpi-enable-bit-11-in-_pdc-to-advertise-hw-coord.patch
+acpi-dock-don-t-eval-_sta-on-every-show_docked-sysfs-read.patch
+ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch
+firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch
+firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch
+firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch
+ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch
+module-remove-over-zealous-check-in-__module_get.patch
+serial-rs485-ioctl-structure-uses-__u32-include-linux-types.h.patch
+x86-apic-enable-workaround-on-amd-fam10h-cpus.patch
+eeepc-laptop-fix-oops-when-changing-backlight-brightness-during-eeepc-laptop-init.patch
+eeepc-laptop-add-support-for-extended-hotkeys.patch
+e1000-fix-bug-with-shared-interrupt-during-reset.patch
+e1000-fix-pci-enable-to-honor-the-need_ioport-flag.patch
+agp-intel-add-support-for-g41-chipset.patch
+agp-intel-fix-broken-symbol-in-device-name.patch
--- /dev/null
+From 361916a943cd9dbda1c0b00879d0225cc919d868 Mon Sep 17 00:00:00 2001
+From: Dean Nelson <dcn@sgi.com>
+Date: Wed, 4 Feb 2009 15:12:24 -0800
+Subject: sgi-xp: fix writing past the end of kzalloc()'d space
+
+From: Dean Nelson <dcn@sgi.com>
+
+commit 361916a943cd9dbda1c0b00879d0225cc919d868 upstream.
+
+A missing type cast results in writing way beyond the end of a kzalloc()'d
+memory segment resulting in slab corruption. But it seems like the better
+solution is to define ->recv_msg_slots as a 'void *' rather than a
+'struct xpc_notify_mq_msg_uv *' and add the type cast.
+
+Signed-off-by: Dean Nelson <dcn@sgi.com>
+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>
+
+---
+ drivers/misc/sgi-xp/xpc.h | 5 +++--
+ drivers/misc/sgi-xp/xpc_uv.c | 11 +++++------
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+--- a/drivers/misc/sgi-xp/xpc.h
++++ b/drivers/misc/sgi-xp/xpc.h
+@@ -3,7 +3,7 @@
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+- * Copyright (c) 2004-2008 Silicon Graphics, Inc. All Rights Reserved.
++ * Copyright (c) 2004-2009 Silicon Graphics, Inc. All Rights Reserved.
+ */
+
+ /*
+@@ -502,7 +502,8 @@ struct xpc_channel_uv {
+ /* partition's notify mq */
+
+ struct xpc_send_msg_slot_uv *send_msg_slots;
+- struct xpc_notify_mq_msg_uv *recv_msg_slots;
++ void *recv_msg_slots; /* each slot will hold a xpc_notify_mq_msg_uv */
++ /* structure plus the user's payload */
+
+ struct xpc_fifo_head_uv msg_slot_free_list;
+ struct xpc_fifo_head_uv recv_msg_list; /* deliverable payloads */
+--- a/drivers/misc/sgi-xp/xpc_uv.c
++++ b/drivers/misc/sgi-xp/xpc_uv.c
+@@ -3,7 +3,7 @@
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+- * Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved.
++ * Copyright (c) 2008-2009 Silicon Graphics, Inc. All Rights Reserved.
+ */
+
+ /*
+@@ -825,8 +825,8 @@ xpc_allocate_recv_msg_slot_uv(struct xpc
+ continue;
+
+ for (entry = 0; entry < nentries; entry++) {
+- msg_slot = ch_uv->recv_msg_slots + entry *
+- ch->entry_size;
++ msg_slot = ch_uv->recv_msg_slots +
++ entry * ch->entry_size;
+
+ msg_slot->hdr.msg_slot_number = entry;
+ }
+@@ -1123,9 +1123,8 @@ xpc_handle_notify_mq_msg_uv(struct xpc_p
+ /* we're dealing with a normal message sent via the notify_mq */
+ ch_uv = &ch->sn.uv;
+
+- msg_slot = (struct xpc_notify_mq_msg_uv *)((u64)ch_uv->recv_msg_slots +
+- (msg->hdr.msg_slot_number % ch->remote_nentries) *
+- ch->entry_size);
++ msg_slot = ch_uv->recv_msg_slots +
++ (msg->hdr.msg_slot_number % ch->remote_nentries) * ch->entry_size;
+
+ BUG_ON(msg->hdr.msg_slot_number != msg_slot->hdr.msg_slot_number);
+ BUG_ON(msg_slot->hdr.size != 0);
--- /dev/null
+From a68e61e8ff2d46327a37b69056998b47745db6fa Mon Sep 17 00:00:00 2001
+From: Tony Battersby <tonyb@cybernetics.com>
+Date: Wed, 4 Feb 2009 15:12:04 -0800
+Subject: shm: fix shmctl(SHM_INFO) lockup with !CONFIG_SHMEM
+
+From: Tony Battersby <tonyb@cybernetics.com>
+
+commit a68e61e8ff2d46327a37b69056998b47745db6fa upstream.
+
+shm_get_stat() assumes that the inode is a "struct shmem_inode_info",
+which is incorrect for !CONFIG_SHMEM (see fs/ramfs/inode.c:
+ramfs_get_inode() vs. mm/shmem.c: shmem_get_inode()).
+
+This bad assumption can cause shmctl(SHM_INFO) to lockup when
+shm_get_stat() tries to spin_lock(&info->lock). Users of !CONFIG_SHMEM
+may encounter this lockup simply by invoking the 'ipcs' command.
+
+Reported by Jiri Olsa back in February 2008:
+http://lkml.org/lkml/2008/2/29/74
+
+Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
+Cc: Jiri Kosina <jkosina@suse.cz>
+Reported-by: Jiri Olsa <olsajiri@gmail.com>
+Cc: Hugh Dickins <hugh@veritas.com>
+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>
+
+---
+ ipc/shm.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -565,11 +565,15 @@ static void shm_get_stat(struct ipc_name
+ struct hstate *h = hstate_file(shp->shm_file);
+ *rss += pages_per_huge_page(h) * mapping->nrpages;
+ } else {
++#ifdef CONFIG_SHMEM
+ struct shmem_inode_info *info = SHMEM_I(inode);
+ spin_lock(&info->lock);
+ *rss += inode->i_mapping->nrpages;
+ *swp += info->swapped;
+ spin_unlock(&info->lock);
++#else
++ *rss += inode->i_mapping->nrpages;
++#endif
+ }
+
+ total++;
--- /dev/null
+From 894dcd78782842924527598b0b764c9b4e679e21 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Fri, 6 Feb 2009 08:13:07 +0100
+Subject: sound: usb-audio: handle wMaxPacketSize for FIXED_ENDPOINT devices
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+commit 894dcd78782842924527598b0b764c9b4e679e21 upstream.
+
+For audio devices that do not have proper audio descriptors (e.g.,
+Edirol UA-20), we use hardcoded parameters from our quirks list.
+However, we must still read the maximum packet size from the standard
+endpoint descriptor; otherwise, we might use packets that are too big
+and therefore rejected by the USB core.
+
+Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/usb/usbaudio.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/usb/usbaudio.c
++++ b/sound/usb/usbaudio.c
+@@ -2966,6 +2966,7 @@ static int create_fixed_stream_quirk(str
+ return -EINVAL;
+ }
+ alts = &iface->altsetting[fp->altset_idx];
++ fp->maxpacksize = le16_to_cpu(get_endpoint(alts, 0)->wMaxPacketSize);
+ usb_set_interface(chip->dev, fp->iface, 0);
+ init_usb_pitch(chip->dev, fp->iface, alts, fp);
+ init_usb_sample_rate(chip->dev, fp->iface, alts, fp, fp->rate_max);
--- /dev/null
+From 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Wed, 4 Feb 2009 15:12:14 -0800
+Subject: wait: prevent exclusive waiter starvation
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 upstream.
+
+With exclusive waiters, every process woken up through the wait queue must
+ensure that the next waiter down the line is woken when it has finished.
+
+Interruptible waiters don't do that when aborting due to a signal. And if
+an aborting waiter is concurrently woken up through the waitqueue, noone
+will ever wake up the next waiter.
+
+This has been observed with __wait_on_bit_lock() used by
+lock_page_killable(): the first contender on the queue was aborting when
+the actual lock holder woke it up concurrently. The aborted contender
+didn't acquire the lock and therefor never did an unlock followed by
+waking up the next waiter.
+
+Add abort_exclusive_wait() which removes the process' wait descriptor from
+the waitqueue, iff still queued, or wakes up the next waiter otherwise.
+It does so under the waitqueue lock. Racing with a wake up means the
+aborting process is either already woken (removed from the queue) and will
+wake up the next waiter, or it will remove itself from the queue and the
+concurrent wake up will apply to the next waiter after it.
+
+Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and
+__wait_on_bit_lock() when they were interrupted by other means than a wake
+up through the queue.
+
+[akpm@linux-foundation.org: coding-style fixes]
+Reported-by: Chris Mason <chris.mason@oracle.com>
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Mentored-by: Oleg Nesterov <oleg@redhat.com>
+Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Cc: Matthew Wilcox <matthew@wil.cx>
+Cc: Chuck Lever <cel@citi.umich.edu>
+Cc: Nick Piggin <nickpiggin@yahoo.com.au>
+Cc: Ingo Molnar <mingo@elte.hu>
+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>
+
+---
+ include/linux/wait.h | 11 +++++++--
+ kernel/sched.c | 4 +--
+ kernel/wait.c | 59 ++++++++++++++++++++++++++++++++++++++++++++-------
+ 3 files changed, 63 insertions(+), 11 deletions(-)
+
+--- a/include/linux/wait.h
++++ b/include/linux/wait.h
+@@ -132,6 +132,8 @@ static inline void __remove_wait_queue(w
+ list_del(&old->task_list);
+ }
+
++void __wake_up_common(wait_queue_head_t *q, unsigned int mode,
++ int nr_exclusive, int sync, void *key);
+ void __wake_up(wait_queue_head_t *q, unsigned int mode, int nr, void *key);
+ extern void __wake_up_locked(wait_queue_head_t *q, unsigned int mode);
+ extern void __wake_up_sync(wait_queue_head_t *q, unsigned int mode, int nr);
+@@ -333,16 +335,19 @@ do { \
+ for (;;) { \
+ prepare_to_wait_exclusive(&wq, &__wait, \
+ TASK_INTERRUPTIBLE); \
+- if (condition) \
++ if (condition) { \
++ finish_wait(&wq, &__wait); \
+ break; \
++ } \
+ if (!signal_pending(current)) { \
+ schedule(); \
+ continue; \
+ } \
+ ret = -ERESTARTSYS; \
++ abort_exclusive_wait(&wq, &__wait, \
++ TASK_INTERRUPTIBLE, NULL); \
+ break; \
+ } \
+- finish_wait(&wq, &__wait); \
+ } while (0)
+
+ #define wait_event_interruptible_exclusive(wq, condition) \
+@@ -431,6 +436,8 @@ extern long interruptible_sleep_on_timeo
+ void prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state);
+ void prepare_to_wait_exclusive(wait_queue_head_t *q, wait_queue_t *wait, int state);
+ void finish_wait(wait_queue_head_t *q, wait_queue_t *wait);
++void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait,
++ unsigned int mode, void *key);
+ int autoremove_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key);
+ int wake_bit_function(wait_queue_t *wait, unsigned mode, int sync, void *key);
+
+--- a/kernel/sched.c
++++ b/kernel/sched.c
+@@ -4586,8 +4586,8 @@ EXPORT_SYMBOL(default_wake_function);
+ * started to run but is not in state TASK_RUNNING. try_to_wake_up() returns
+ * zero in this (rare) case, and we handle it by continuing to scan the queue.
+ */
+-static void __wake_up_common(wait_queue_head_t *q, unsigned int mode,
+- int nr_exclusive, int sync, void *key)
++void __wake_up_common(wait_queue_head_t *q, unsigned int mode,
++ int nr_exclusive, int sync, void *key)
+ {
+ wait_queue_t *curr, *next;
+
+--- a/kernel/wait.c
++++ b/kernel/wait.c
+@@ -91,6 +91,15 @@ prepare_to_wait_exclusive(wait_queue_hea
+ }
+ EXPORT_SYMBOL(prepare_to_wait_exclusive);
+
++/*
++ * finish_wait - clean up after waiting in a queue
++ * @q: waitqueue waited on
++ * @wait: wait descriptor
++ *
++ * Sets current thread back to running state and removes
++ * the wait descriptor from the given waitqueue if still
++ * queued.
++ */
+ void finish_wait(wait_queue_head_t *q, wait_queue_t *wait)
+ {
+ unsigned long flags;
+@@ -117,6 +126,39 @@ void finish_wait(wait_queue_head_t *q, w
+ }
+ EXPORT_SYMBOL(finish_wait);
+
++/*
++ * abort_exclusive_wait - abort exclusive waiting in a queue
++ * @q: waitqueue waited on
++ * @wait: wait descriptor
++ * @state: runstate of the waiter to be woken
++ * @key: key to identify a wait bit queue or %NULL
++ *
++ * Sets current thread back to running state and removes
++ * the wait descriptor from the given waitqueue if still
++ * queued.
++ *
++ * Wakes up the next waiter if the caller is concurrently
++ * woken up through the queue.
++ *
++ * This prevents waiter starvation where an exclusive waiter
++ * aborts and is woken up concurrently and noone wakes up
++ * the next waiter.
++ */
++void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait,
++ unsigned int mode, void *key)
++{
++ unsigned long flags;
++
++ __set_current_state(TASK_RUNNING);
++ spin_lock_irqsave(&q->lock, flags);
++ if (!list_empty(&wait->task_list))
++ list_del_init(&wait->task_list);
++ else if (waitqueue_active(q))
++ __wake_up_common(q, mode, 1, 0, key);
++ spin_unlock_irqrestore(&q->lock, flags);
++}
++EXPORT_SYMBOL(abort_exclusive_wait);
++
+ int autoremove_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key)
+ {
+ int ret = default_wake_function(wait, mode, sync, key);
+@@ -177,17 +219,20 @@ int __sched
+ __wait_on_bit_lock(wait_queue_head_t *wq, struct wait_bit_queue *q,
+ int (*action)(void *), unsigned mode)
+ {
+- int ret = 0;
+-
+ do {
++ int ret;
++
+ prepare_to_wait_exclusive(wq, &q->wait, mode);
+- if (test_bit(q->key.bit_nr, q->key.flags)) {
+- if ((ret = (*action)(q->key.flags)))
+- break;
+- }
++ if (!test_bit(q->key.bit_nr, q->key.flags))
++ continue;
++ ret = action(q->key.flags);
++ if (!ret)
++ continue;
++ abort_exclusive_wait(wq, &q->wait, mode, &q->key);
++ return ret;
+ } while (test_and_set_bit(q->key.bit_nr, q->key.flags));
+ finish_wait(wq, &q->wait);
+- return ret;
++ return 0;
+ }
+ EXPORT_SYMBOL(__wait_on_bit_lock);
+
--- /dev/null
+From 858770619debfb9269add63e4ba8b7c6b5538dd1 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <borislav.petkov@amd.com>
+Date: Tue, 3 Feb 2009 16:24:22 +0100
+Subject: x86: APIC: enable workaround on AMD Fam10h CPUs
+
+From: Borislav Petkov <borislav.petkov@amd.com>
+
+commit 858770619debfb9269add63e4ba8b7c6b5538dd1 upstream.
+
+Impact: fix to enable APIC for AMD Fam10h on chipsets with a missing/b0rked
+ ACPI MP table (MADT)
+
+Booting a 32bit kernel on an AMD Fam10h CPU running on chipsets with
+missing/b0rked MP table leads to a hang pretty early in the boot process
+due to the APIC not being initialized. Fix that by falling back to the
+default APIC base address in 32bit code, as it is done in the 64bit
+codepath.
+
+Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/apic.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/apic.c
++++ b/arch/x86/kernel/apic.c
+@@ -1451,7 +1451,7 @@ static int __init detect_init_APIC(void)
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_AMD:
+ if ((boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model > 1) ||
+- (boot_cpu_data.x86 == 15))
++ (boot_cpu_data.x86 >= 15))
+ break;
+ goto no_apic;
+ case X86_VENDOR_INTEL:
projects / thirdparty / kernel / stable-queue.git / commitdiff
