commit 938b773dac5b933f133f9158b796ba0f29c4ea52 Author: Greg Kroah-Hartman Date: Thu Jul 24 09:14:20 2008 -0700 Linux 2.6.25.12 commit 1696e9ec406506328258cee60ed4ba4a217a5d1c Author: Alexander Simon Date: Sat Mar 29 21:37:54 2008 -0300 V4L/DVB (7475): Added support for Terratec Cinergy T USB XXS commit dc88807ed61ed0fc0d57bd80a92508b9de638f5d upstream. Alexander Simon found out that the Terratec Cinergy T USB XXS is just a clone of another DiB7070P-based device. Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab Cc: Ludwig Nussel Signed-off-by: Greg Kroah-Hartman commit 7605f791515eea189e956db44b5a404bd93b29dc Author: Steven Rostedt Date: Thu Jul 3 14:31:26 2008 -0400 hrtimer: prevent migration for raising softirq commit ee3ece830f6db9837f7ac67008f532a8c1e755f4 upstream. Due to a possible deadlock, the waking of the softirq was pushed outside of the hrtimer base locks. See commit 0c96c5979a522c3323c30a078a70120e29b5bdbc Unfortunately this allows the task to migrate after setting up the softirq and raising it. Since softirqs run a queue that is per-cpu we may raise the softirq on the wrong CPU and this will keep the queued softirq task from running. To solve this issue, this patch disables preemption around the releasing of the hrtimer lock and raising of the softirq. Signed-off-by: Steven Rostedt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c23d253e757a7514ec160fb7fdb0d3ba558b8f6a Author: Pierre Ossman Date: Fri Jul 4 12:51:20 2008 +0200 mmc: don't use DMA on newer ENE controllers commit bf5b1935d8e42b36a34645788eb261461fe07f2e upstream. Even the newer ENE controllers have bugs in their DMA engine that make it too dangerous to use. Disable it until someone has figured out under which conditions it corrupts data. This has caused problems at least once, and can be found as bug report 10925 in the kernel bugzilla. Signed-off-by: Pierre Ossman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4fa47616fec25ffc3e19ace5f3f06f4cd302d69e Author: Karl Beldan Date: Wed Jul 16 18:29:11 2008 +0200 pxamci: trivial fix of DMA alignment register bit clearing commit 4fe16897c59882420d66f2d503106653d026ed6c upstream Signed-off-by: Karl Beldan Acked-by: Eric Miao Signed-off-by: Pierre Ossman Signed-off-by: Greg Kroah-Hartman commit 708cc88d265a25f51dec199caa89aaee60967b3b Author: Philipp Zabel Date: Sun Jul 6 01:15:34 2008 +0200 pxamci: fix byte aligned DMA transfers commit 97f8571e663c808ad2d01a396627235167291556 upstream The pxa27x DMA controller defaults to 64-bit alignment. This caused the SCR reads to fail (and, depending on card type, error out) when card->raw_scr was not aligned on a 8-byte boundary. For performance reasons all scatter-gather addresses passed to pxamci_request should be aligned on 8-byte boundaries, but if this can't be guaranteed, byte aligned DMA transfers in the have to be enabled in the controller to get correct behaviour. Signed-off-by: Philipp Zabel Signed-off-by: Pierre Ossman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0a96934becd9759b4dbf247226557c22abd12824 Author: Vitaly Bordug Date: Wed Jul 9 13:13:38 2008 +1000 powerpc: Add missing reference to coherent_dma_mask commit ba0fc709e197415aadd46b9ec208dc4abaa21edd upstream There is dma_mask in of_device upon of_platform_device_create() but we don't actually set coherent_dma_mask. This may cause weird behavior of USB subsystem using of_device USB host drivers. Signed-off-by: Vitaly Bordug Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c2bd04d8040a91fe2ee2e9fee1a6562ca9792249 Author: Herbert Xu Date: Mon Jul 14 14:46:07 2008 +0800 crypto: chainiv - Invoke completion function Upstream commit: 872ac8743cb400192a9fce4ba2d3ffd7bb309685 When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e505e03b6737b07e04efa9ed1f59eefc2e8532bc Author: James Bottomley Date: Sat Jul 12 21:40:51 2008 +0000 SCSI: mptspi: fix oops in mptspi_dv_renegotiate_work() commit 081a5bcb39b455405d58f79bb3c9398a9d4477ed upstream The problem here is that if the ioc faults too early in the bring up sequence (as it usually does for an irq routing problem), ioc_reset gets called before the scsi host is even allocated. This causes an oops when it later schedules a renegotiation. Fix this by checking ioc->sh before trying to renegotiate. Cc: Eric Moore Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 4195cdf72c4060e4a9527c49ac5267234b0624de Author: Darren Jenkins Date: Sat Jul 12 21:40:47 2008 +0000 drivers/char/pcmcia/ipwireless/hardware.c fix resource leak commit 43f77e91eadbc290eb76a08110a039c809dde6c9 upstream Coverity CID: 2172 RESOURCE_LEAK When pool_allocate() tries to enlarge a packet, if it can not allocate enough memory, it returns NULL without first freeing the old packet. This patch just frees the packet first. Signed-off-by: Darren Jenkins Acked-by: Jiri Kosina Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eb2707cf66b1e921a54822a56443f756a161b09a Author: Darren Jenkins Date: Sat Jul 12 21:40:43 2008 +0000 drivers/isdn/i4l/isdn_common.c fix small resource leak commit 4fc89e3911aa5357b55b85b60c4beaeb8a48a290 upstream Coverity CID: 1356 RESOURCE_LEAK I found a very old patch for this that was Acked but did not get applied https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when copy_from_user() returns an un-copied data length (length != 0). The below patch should be a minimally invasive fix. Signed-off-by: Darren Jenkins Acked-by: Karsten Keil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 043ce6e2d71a5111b8f237da119336007f29b033 Author: Jaya Kumar Date: Sat Jul 12 21:40:37 2008 +0000 fbdev: bugfix for multiprocess defio commit f31ad92f34913043cf008d6e479e92dfbaf02df1 upstream This patch is a bugfix for how defio handles multiple processes manipulating the same framebuffer. Thanks to Bernard Blackham for identifying this bug. It occurs when two applications mmap the same framebuffer and concurrently write to the same page. Normally, this doesn't occur since only a single process mmaps the framebuffer. The symptom of the bug is that the mapping applications will hang. The cause is that defio incorrectly tries to add the same page twice to the pagelist. The solution I have is to walk the pagelist and check for a duplicate before adding. Since I needed to walk the pagelist, I now also keep the pagelist in sorted order. Signed-off-by: Jaya Kumar Cc: Bernard Blackham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 57dc6158b397beba881fa405cbafcfb99b57dd5e Author: Eric W. Biederman Date: Sat Jul 12 21:40:32 2008 +0000 serial8250: sanity check nr_uarts on all paths. commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird mysterious crash in sysfs. After taking an in-depth look I realized that CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of the serial8250_ports array. Ouch!!! Don't let this happen to someone else. Signed-off-by: Eric W. Biederman Acked-by: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 94db799b920539daf593ab48365ee0d71ce3dbf7 Author: Andres Salomon Date: Sat Jul 12 21:40:27 2008 +0000 ov7670: clean up ov7670_read semantics commit bca5c2c550f16d2dc2d21ffb7b4712bd0a7d32a9 upstream Cortland Setlow pointed out a bug in ov7670.c where the result from ov7670_read() was just being checked for !0, rather than <0. This made me realize that ov7670_read's semantics were rather confusing; it both fills in 'value' with the result, and returns it. This is goes against general kernel convention; so rather than fixing callers, let's fix the function. This makes ov7670_read return <0 in the case of an error, and 0 upon success. Thus, code like: res = ov7670_read(...); if (!res) goto error; .will work properly. Signed-off-by: Cortland Setlow Signed-off-by: Andres Salomon Acked-by: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d961e684e6e0735492e0644ca06bbeb7919ccc2 Author: Jeff Layton Date: Sat Jul 12 21:40:22 2008 +0000 cifs: fix wksidarr declaration to be big-endian friendly commit 536abdb0802f3fac1b217530741853843d63c281 upstream The current definition of wksidarr works fine on little endian arches (since cpu_to_le32 is a no-op there), but on big-endian arches, it fails to compile with this error: error: braced-group within expression allowed only inside a function The problem is that this static declaration has cpu_to_le32 embedded within it, and that expands into a function macro. We need to use __constant_cpu_to_le32() instead. Signed-off-by: Jeff Layton Cc: Steven French Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6274fd5bf0b757543e7600c749d9cd33246a3131 Author: Marcin Obara Date: Fri Jul 11 18:40:10 2008 +0000 tpm: add Intel TPM TIS device HID commit fb0e7e11d017beb5f0b1fa25bc51e49e65c46d67 upstream This patch adds Intel TPM TIS device HID: ICO0102 Signed-off-by: Marcin Obara Acked-by: Marcel Selhorst Acked-by: Rajiv Andrade Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 42803939f3f128d9415a01a4731f7ac21c1b24fc Author: Eugene Surovegin Date: Fri Jul 11 18:40:07 2008 +0000 rapidio: fix device reference counting commit a7de3902edce099e4102c1272ec0ab569c1791f7 upstream Fix RapidIO device reference counting. Signed-of-by: Eugene Surovegin Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0e8c03ccf3066ac4768936df5adf23c9ce340784 Author: Paul Gortmaker Date: Fri Jul 11 18:40:03 2008 +0000 rtc: fix reported IRQ rate for when HPET is enabled commit 61ca9daa2ca3022dc9cb22bd98e69c1b61e412ad upstream The IRQ rate reported back by the RTC is incorrect when HPET is enabled. Newer hardware that has HPET to emulate the legacy RTC device gets this value wrong since after it sets the rate, it returns before setting the variable used to report the IRQ rate back to users of the device -- so the set rate and the reported rate get out of sync. Signed-off-by: Paul Gortmaker Cc: Ingo Molnar Cc: David Brownell Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 46c88e2962809828a5105478f2a51d2ad10499d8 Author: Dmitry Adamushko Date: Fri Jul 11 01:20:02 2008 +0000 slub: Fix use-after-preempt of per-CPU data structure commit bdb21928512a860a60e6a24a849dc5b63cbaf96a upstream Vegard Nossum reported a crash in kmem_cache_alloc(): BUG: unable to handle kernel paging request at da87d000 IP: [] kmem_cache_alloc+0xc7/0xe0 *pde = 28180163 *pte = 1a87d160 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 3850, comm: grep Not tainted (2.6.26-rc9-00059-gb190333 #5) EIP: 0060:[] EFLAGS: 00210203 CPU: 0 EIP is at kmem_cache_alloc+0xc7/0xe0 EAX: 00000000 EBX: da87c100 ECX: 1adad71a EDX: 6b6b6b6b ESI: 00200282 EDI: da87d000 EBP: f60bfe74 ESP: f60bfe54 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 and analyzed it: "The register %ecx looks innocent but is very important here. The disassembly: mov %edx,%ecx shr $0x2,%ecx rep stos %eax,%es:(%edi) <-- the fault So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE. (0x6b6b6b6b >> 2 == 0x1adadada.) %ecx is the counter for the memset, from here: memset(object, 0, c->objsize); i.e. %ecx was loaded from c->objsize, so "c" must have been freed. Where did "c" come from? Uh-oh... c = get_cpu_slab(s, smp_processor_id()); This looks like it has very much to do with CPU hotplug/unplug. Is there a race between SLUB/hotplug since the CPU slab is used after it has been freed?" Good analysis. Yeah, it's possible that a caller of kmem_cache_alloc() -> slab_alloc() can be migrated on another CPU right after local_irq_restore() and before memset(). The inital cpu can become offline in the mean time (or a migration is a consequence of the CPU going offline) so its 'kmem_cache_cpu' structure gets freed ( slab_cpuup_callback). At some point of time the caller continues on another CPU having an obsolete pointer... Signed-off-by: Dmitry Adamushko Reported-by: Vegard Nossum Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 557717021c28965902b9cfd6d2c60db90c492078 Author: Hugh Dickins Date: Thu Jul 10 20:45:02 2008 +0000 exec: fix stack excutability without PT_GNU_STACK commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32) exec'ing an ELF without a PT_GNU_STACK program header should default to an executable stack; but this got broken by the unlimited argv feature because stack vma is now created before the right personality has been established: so breaking old binaries using nested function trampolines. Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack vm_flags used to be set, before the mprotect_fixup. Checking through our existing VM_flags, none would have changed since insert_vm_struct: so this seems safer than finding a way through the personality labyrinth. Reported-by: pageexec@freemail.hu Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff7d5b4baa216406b83aabfed5714e0919da7e56 Author: Firat Birlik Date: Fri Jul 4 04:31:50 2008 +0100 zd1211rw: add ID for AirTies WUS-201 Commit 9dfd55008e3863dcd93219c74bf05b09e5c549e2 upstream I would like to inform you of our zd1211 based usb wifi adapter (AirTies WUS-201), which works with the zd1211rw driver with the following device id definition. Signed-off-by: Daniel Drake Signed-off-by: John W. Linville Cc: Peter Nixon Signed-off-by: Greg Kroah-Hartman commit ea1bb944a0a2f98350648dcc801c64b11fd7c186 Author: Jozsef Kadlecsik Date: Mon Jul 7 15:57:03 2008 +0200 netfilter: nf_conntrack_tcp: fixing to check the lower bound of valid ACK Upstream commit 84ebe1c: Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on the netfilter mailing list (see the thread "Weird nat/conntrack Problem with PASV FTP upload"). He provided tcpdump recordings which helped to find a long lingering bug in conntrack. In TCP connection tracking, checking the lower bound of valid ACK could lead to mark valid packets as INVALID because: - We have got a "higher or equal" inequality, but the test checked the "higher" condition only; fixed. - If the packet contains a SACK option, it could occur that the ACK value was before the left edge of our (S)ACK "window": if a previous packet from the other party intersected the right edge of the window of the receiver, we could move forward the window parameters beyond accepting a valid ack. Therefore in this patch we check the rightmost SACK edge instead of the ACK value in the lower bound of valid (S)ACK test. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller commit 3fa6bcb587adefb2ed2391297529cbead8f03e0a Author: Joonwoo Park Date: Mon Jul 7 15:56:57 2008 +0200 textsearch: fix Boyer-Moore text search bug Upstream commit aebb6a849cfe7d89bcacaaecc20a480dfc1180e7 The current logic has a bug which cannot find matching pattern, if the pattern is matched from the first character of target string. for example: pattern=abc, string=abcdefg pattern=a, string=abcdefg Searching algorithm should return 0 for those things. Signed-off-by: Joonwoo Park Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller commit fc46a59f78a80dc3957a00badaca2737ddf7fbfd Author: Dan Williams Date: Thu Jul 10 18:15:04 2008 +0000 md: ensure all blocks are uptodate or locked when syncing commit 7a1fc53c5adb910751a9b212af90302eb4ffb527 upstream Remove the dubious attempt to prefer 'compute' over 'read'. Not only is it wrong given commit c337869d (md: do not compute parity unless it is on a failed drive), but it can trigger a BUG_ON in handle_parity_checks5(). Signed-off-by: Dan Williams Signed-off-by: Neil Brown Signed-off-by: Greg Kroah-Hartman commit ba9ecf2c7d4c64b3118260f5a056337e41a2612c Author: Will Newton Date: Fri Jun 27 13:08:08 2008 +0100 sisusbvga: Fix oops on disconnect. commit f15e39739a1d7dfaa2173a91707a74c11a246648 upstream Remove dev_info call on disconnect. The sisusb_dev pointer may have been set to zero by sisusb_delete at this point causing an oops. The message does not provide any extra information over the standard USB subsystem output so removing it does not affect functionality. Signed-off-by: Will Newton Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6c5294c62492e0188fcf0d430463f900d96c0159 Author: Oliver Hartkopp Date: Tue Jul 8 18:34:50 2008 +0200 can: add sanity checks commit 7f2d38eb7a42bea1c1df51bbdaa2ca0f0bdda07f upstream Even though the CAN netlayer only deals with CAN netdevices, the netlayer interface to the userspace and to the device layer should perform some sanity checks. This patch adds several sanity checks that mainly prevent userspace apps to send broken content into the system that may be misinterpreted by some other userspace application. Signed-off-by: Oliver Hartkopp Signed-off-by: Urs Thuermann Acked-by: Andre Naujoks Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81c5896b8f697f5135153055e15cf52da375095a Author: Guennadi Liakhovetski Date: Fri Jul 4 20:05:29 2008 +0000 serial: fix serial_match_port() for dynamic major tty-device numbers commit 7ca796f492a11f9408e661c8f22cd8c4f486b8e5 upstream As reported by Vipul Gandhi, the current serial_match_port() doesn't work for tty-devices using dynamic major number allocation. Fix it. It oopses if you suspend a serial port with _dynamic_ major number. ATM, I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that does it in-tree. Signed-off-by: Guennadi Liakhovetski Tested-by: Vipul Gandhi Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aeb36f4e43e8af7677a5f72be48e4751cf9e6eb2 Author: Mike Miller Date: Fri Jul 4 20:05:25 2008 +0000 cciss: read config to obtain max outstanding commands per controller commit 491539982aa01fa71de93c2a06ac5d890d4cf1e2 upstream This patch changes the way we determine the maximum number of outstanding commands for each controller. Most Smart Array controllers can support up to 1024 commands, the notable exceptions are the E200 and E200i. The next generation of controllers which were just added support a mode of operation called Zero Memory Raid (ZMR). In this mode they only support 64 outstanding commands. In Full Function Raid (FFR) mode they support 1024. We have been setting the queue depth by arbitrarily assigning some value for each controller. We needed a better way to set the queue depth to avoid lots of annoying "fifo full" messages. So we made the driver a little smarter. We now read the config table and subtract 4 from the returned value. The -4 is to allow some room for ioctl calls which are not tracked the same way as io commands are tracked. Please consider this for inclusion. Signed-off-by: Mike Miller Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce07e7b0991a0a3171e97ca76f1cc576ba88e787 Author: Jeff Mahoney Date: Tue Jul 8 14:37:06 2008 -0400 reiserfs: discard prealloc in reiserfs_delete_inode commit eb35c218d83ec0780d9db869310f2e333f628702 upstream With the removal of struct file from the xattr code, reiserfs_file_release() isn't used anymore, so the prealloc isn't discarded. This causes hangs later down the line. This patch adds it to reiserfs_delete_inode. In most cases it will be a no-op due to it already having been called, but will avoid hangs with xattrs. Signed-off-by: Jeff Mahoney Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3ec116ffe5e2085f1a9c63a87e64d86b85e7b81e Author: John Blackwood Date: Fri Jul 4 10:00:05 2008 -0700 mm: switch node meminfo Active & Inactive pages to Kbytes commit 2d5c1be8870383622809c25935fff00d2630c7a5 upstream There is a bug in the output of /sys/devices/system/node/node[n]/meminfo where the Active and Inactive values are in pages instead of Kbytes. Looks like this occurred back in 2.6.20 when the code was changed over to use node_page_state(). Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 84671354a49a26e169f08b35ad0884902732bacc Author: Matthew Wilcox Date: Thu Jul 3 02:45:51 2008 +0000 SCSI: ses: Fix timeout commit c95e62ce8905aab62fed224eaaa9b8558a0ef652 upstream Timeouts are measured in jiffies, not in seconds. Signed-off-by: Matthew Wilcox Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a342eed928f29065bd69fe7bb000a3fdbc25ef88 Author: James Bottomley Date: Thu Jul 3 02:45:44 2008 +0000 SCSI: esp: tidy up target reference counting commit ec5e69f6d3f4350681d6f7eaae515cf014be9276 upstream The esp driver currently does hand rolled reference counting of its target. It's much easier to do what it needs to do if it's plugged into the mid-layer callbacks (target_alloc and target_destroy) which were designed for this case, so do it this way and get rid of the internal target reference count. Acked-by: David S. Miller Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 13ac0ea3cf0b540c409d5a5ff1508f2d630d475d Author: David S. Miller Date: Thu Jul 3 02:45:49 2008 +0000 SCSI: esp: Fix OOPS in esp_reset_cleanup(). commit eadc49b1a8d09480f14caea292142f103a89c77a upstream OOPS reported by Friedrich Oslage The problem here is that tp->starget is set every time a lun is allocated for a particular target so we can catch the sdev_target parent value. The reset handler uses the NULL'ness of this value to determine which targets are active. But esp_slave_destroy() does not NULL out this value when appropriate. So for every target that doesn't respond, the SCSI bus scan causes a stale pointer to be left here, with ensuing crashes like you're seeing. Signed-off-by: David S. Miller Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b80a43a3627d4dede30e59706443dc1653f5e2de Author: Ingo Molnar Date: Thu Jul 3 02:45:40 2008 +0000 netdrvr: 3c59x: remove irqs_disabled warning from local_bh_enable commit c5643cab7bf663ae049b11be43de8819683176dd upstream Original Author: Michael Buesch net, vortex: fix lockup Ingo Molnar reported: -tip testing found that Johannes Berg's "softirq: remove irqs_disabled warning from local_bh_enable" enhancement to lockdep triggers a new warning on an old testbox that uses 3c59x vortex and netlogging: -----> calling vortex_init+0x0/0xb0 PCI: Found IRQ 10 for device 0000:00:0b.0 PCI: Sharing IRQ 10 with 0000:00:0a.0 PCI: Sharing IRQ 10 with 0000:00:0b.1 3c59x: Donald Becker and others. 0000:00:0b.0: 3Com PCI 3c556 Laptop Tornado at e0800400. PCI: Enabling bus mastering for device 0000:00:0b.0 initcall vortex_init+0x0/0xb0 returned 0 after 47 msecs .. calling init_netconsole+0x0/0x1b0 netconsole: local port 4444 netconsole: local IP 10.0.1.9 netconsole: interface eth0 netconsole: remote port 4444 netconsole: remote IP 10.0.1.16 netconsole: remote ethernet address 00:19:xx:xx:xx:xx netconsole: device eth0 not up yet, forcing it eth0: setting half-duplex. eth0: setting full-duplex. ------------[ cut here ]------------ WARNING: at kernel/softirq.c:137 local_bh_enable_ip+0xd1/0xe0() Pid: 1, comm: swapper Not tainted 2.6.26-rc6-tip #2091 [] warn_on_slowpath+0x4f/0x70 [] ? release_console_sem+0x1b4/0x1d0 [] ? vprintk+0x2a0/0x450 [] ? __mod_timer+0xa5/0xc0 [] ? mdio_sync+0x3d/0x50 [] ? marker_probe_cb+0x46/0xa0 [] ? printk+0x27/0x50 [] ? vortex_set_duplex+0x43/0xc0 [] ? vortex_set_duplex+0xa1/0xc0 [] ? vortex_timer+0xe2/0x3e0 [] local_bh_enable_ip+0xd1/0xe0 [] _spin_unlock_bh+0x2f/0x40 [] vortex_timer+0xe2/0x3e0 [] ? trace_hardirqs_on+0xb/0x10 [] ? trace_hardirqs_on_caller+0x88/0x160 [] run_timer_softirq+0x162/0x1c0 [] ? vortex_timer+0x0/0x3e0 [] local_bh_enable_ip+0xd1/0xe0 [] _spin_unlock_bh+0x2f/0x40 [] vortex_timer+0xe2/0x3e0 [] ? trace_hardirqs_on+0xb/0x10 [] ? trace_hardirqs_on_caller+0x88/0x160 [] run_timer_softirq+0x162/0x1c0 [] ? vortex_timer+0x0/0x3e0 [] ? vortex_timer+0x0/0x3e0 [] __do_softirq+0x9a/0x160 [] ? __do_softirq+0x0/0x160 [] call_on_stack+0x15/0x30 [] ? irq_exit+0x55/0x60 [] ? do_IRQ+0x85/0xd0 [] ? trace_hardirqs_on_caller+0xc1/0x160 [] ? common_interrupt+0x28/0x30 [] ? mutex_unlock+0x8/0x10 [] ? _cond_resched+0x10/0x30 [] ? netpoll_setup+0x117/0x390 [] ? init_netconsole+0x14e/0x1b0 [] ? ktime_get+0x19/0x40 [] ? kernel_init+0x1b2/0x2c0 [] ? init_netconsole+0x0/0x1b0 [] ? trace_hardirqs_on_thunk+0xc/0x10 [] ? restore_nocheck_notrace+0x0/0xe [] ? kernel_init+0x0/0x2c0 [] ? kernel_init+0x0/0x2c0 [] ? kernel_thread_helper+0x7/0x10 ======================= ---[ end trace 37f9c502aff112e0 ]--- console [netcon0] enabled netconsole: network logging started initcall init_netconsole+0x0/0x1b0 returned 0 after 2914 msecs looking at the driver I think the bug is real and the fix actually is trivial. vp->lock is also taken in hardware IRQ context, so we _have_ to always use irqsafe locking. As we run in a timer with IRQs disabled, we can simply use spin_lock. Signed-off-by: Ingo Molnar Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 79ec0fb601c989adf6180a13a74fb761ce90e522 Author: Michael Buesch Date: Thu Jul 3 02:45:47 2008 +0000 b43legacy: Fix possible NULL pointer dereference in DMA code commit 2f9ec47d0954f9d2e5a00209c2689cbc477a8c89 upstream This fixes a possible NULL pointer dereference in an error path of the DMA allocation error checking code. This is also necessary for a future DMA API change that is on its way into the mainline kernel that adds an additional dev parameter to dma_mapping_error(). Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d9fa0e1e5ba2b33448f9398fd0b129388e09a591 Author: maximilian attems Date: Fri Jul 4 09:59:43 2008 -0700 hdaps: add support for various newer Lenovo thinkpads commit 292d73551d0aa19526c3417e791c529b49ebadf3 upstream Adds R61, T61p, X61s, X61, Z61m, Z61p models to whitelist. Fixes this: cullen@lenny:~$ sudo modprobe hdaps FATAL: Error inserting hdaps (/lib/modules/2.6.22-10-generic/kernel/drivers/hwmon/hdaps.ko): No such device [25192.888000] hdaps: supported laptop not found! [25192.888000] hdaps: driver init failed (ret=-19)! Originally based on an Ubuntu patch that got it wrong, the dmidecode output of the corresponding laptops shows LENOVO as the manufacturer. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133636 tested on X61s: [ 184.893588] hdaps: inverting axis readings. [ 184.893588] hdaps: LENOVO ThinkPad X61s detected. [ 184.893588] input: hdaps as /class/input/input12 [ 184.924326] hdaps: driver successfully loaded. Cc: Klaus S. Madsen Cc: Chuck Short Cc: Jean Delvare Cc: Tim Gardner Signed-off-by: maximilian attems Cc: Mark M. Hoffman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 81eea6171b6683ca824dd4b0144f37c2684ac54a Author: Stefan Becker Date: Fri Jul 4 05:20:27 2008 +0000 USB: fix interrupt disabling for HCDs with shared interrupt handlers commit de85422b94ddb23c021126815ea49414047c13dc upstream As has been discussed several times on LKML, IRQF_SHARED | IRQF_DISABLED doesn't work reliably, i.e. a shared interrupt handler CAN'T be certain to be called with interrupts disabled. Most USB HCD handlers use IRQF_DISABLED and therefore havoc can break out if they share their interrupt with a handler that doesn't use it. On my test machine the yenta_socket interrupt handler (no IRQF_DISABLED) was registered before ehci_hcd and one uhci_hcd instance. Therefore all usb_hcd_irq() invocations for ehci_hcd and for one uhci_hcd instance happened with interrupts enabled. That led to random lockups as USB core HCD functions that acquire the same spinlock could be called twice from interrupt handlers. This patch updates usb_hcd_irq() to always disable/restore interrupts. usb_add_hcd() will silently remove any IRQF_DISABLED requested from HCD code. Signed-off-by: Stefan Becker Acked-by: David Brownell Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 5886d647e65a89f75a5a5506481e5385857cac4c Author: David Brownell Date: Fri Jul 4 05:20:28 2008 +0000 USB: ohci - record data toggle after unlink commit 29c8f6a727a683b5988877dd80dbdefd49e64a51 upstream This patch fixes a problem with OHCI where canceling bulk or interrupt URBs may lose track of the right data toggle. This seems to be a longstanding bug, possibly dating back to the Linux 2.4 kernel, which stayed hidden because (a) about half the time the data toggle bit was correct; (b) canceling such URBs is unusual; and (c) the few drivers which cancel these URBs either [1] do it only as part of shutting down, or [2] have fault recovery logic, which recovers. For those transfer types, the toggle is normally written back into the ED when each TD is retired. But canceling bypasses the mechanism used to retire TDs ... so on average, half the time the toggle bit will be invalid after cancelation. The fix is simple: the toggle state of any canceled TDs are propagated back to the ED in the finish_unlinks function. (Issue found by leonidv11@gmail.com ...) Signed-off-by: David Brownell Cc: Leonid Signed-off-by: Greg Kroah-Hartman commit 924906d7e3b72d90c7cc2449a84bfd16c17e2121 Author: David Brownell Date: Fri Jul 4 05:20:28 2008 +0000 USB: ehci - fix timer regression commit 056761e55c8687ddf3db14226213f2e8dc2689bc upstream This patch fixes a regression in the EHCI driver's TIMER_IO_WATCHDOG behavior. The patch "USB: EHCI: add separate IAA watchdog timer" changed how that timer is handled, so that short timeouts on the remaining timer (unfortunately, overloaded) would never be used. This takes a more direct approach, reorganizing the code slightly to be explicit about only the I/O watchdog role now being overridable. It also replaces a now-obsolete comment describing older timer behavior. Signed-off-by: David Brownell Cc: Alan Stern Cc: Leonid Signed-off-by: Greg Kroah-Hartman commit c23e405b53aff53f884465c6612a7bb5a222e078 Author: Ben Dooks Date: Fri Jul 4 05:20:29 2008 +0000 OHCI: Fix problem if SM501 and another platform driver is selected commit 3ee38d8bf46b364b1ca364ddb7c379a4afcd8bbb upstream If the SM501 and another platform driver, such as the SM501 then we end up defining PLATFORM_DRIVER twice. This patch seperated the SM501 onto a seperate define of SM501_OHCI_DRIVER so that it can be selected without overwriting the original definition. Signed-off-by: Ben Dooks Acked-by: David Brownell Signed-off-by: Greg Kroah-Hartman commit 58a60dff37be85dbb58371f360958a82c0c4d8d0 Author: Jens Axboe Date: Tue Jul 1 09:07:34 2008 +0200 block: Properly notify block layer of sync writes commit 18ce3751ccd488c78d3827e9f6bf54e6322676fb upstream fsync_buffers_list() and sync_dirty_buffer() both issue async writes and then immediately wait on them. Conceptually, that makes them sync writes and we should treat them as such so that the IO schedulers can handle them appropriately. This patch fixes a write starvation issue that Lin Ming reported, where xx is stuck for more than 2 minutes because of a large number of synchronous IO in the system: INFO: task kjournald:20558 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kjournald D ffff810010820978 6712 20558 2 ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2 ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb 0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537 Call Trace: [] kobject_get+0x12/0x17 [] getnstimeofday+0x2f/0x83 [] sync_buffer+0x0/0x3f [] io_schedule+0x5d/0x9f [] sync_buffer+0x3b/0x3f [] __wait_on_bit+0x40/0x6f [] sync_buffer+0x0/0x3f [] out_of_line_wait_on_bit+0x6c/0x78 [] wake_bit_function+0x0/0x23 [] sync_dirty_buffer+0x98/0xcb [] journal_commit_transaction+0x97d/0xcb6 [] lock_timer_base+0x26/0x4b [] kjournald+0xc1/0x1fb [] autoremove_wake_function+0x0/0x2e [] kjournald+0x0/0x1fb [] kthread+0x47/0x74 [] schedule_tail+0x28/0x5d [] child_rip+0xa/0x12 [] kthread+0x0/0x74 [] child_rip+0x0/0x12 Lin Ming confirms that this patch fixes the issue. I've run tests with it for the past week and no ill effects have been observed, so I'm proposing it for inclusion into 2.6.26. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a9299439eef2f289f874e21e052998c78e8007e6 Author: Neil Brown Date: Thu Jul 3 02:45:38 2008 +0000 md: Ensure interrupted recovery completed properly (v1 metadata plus bitmap) commit 8c2e870a625bd336b2e7a65a97c1836acef07322 upstream If, while assembling an array, we find a device which is not fully in-sync with the array, it is important to set the "fullsync" flags. This is an exact analog to the setting of this flag in hot_add_disk methods. Currently, only v1.x metadata supports having devices in an array which are not fully in-sync (it keep track of how in sync they are). The 'fullsync' flag only makes a difference when a write-intent bitmap is being used. In this case it tells recovery to ignore the bitmap and recovery all blocks. This fix is already in place for raid1, but not raid5/6 or raid10. So without this fix, a raid1 ir raid4/5/6 array with version 1.x metadata and a write intent bitmaps, that is stopped in the middle of a recovery, will appear to complete the recovery instantly after it is reassembled, but the recovery will not be correct. If you might have an array like that, issueing echo repair > /sys/block/mdXX/md/sync_action will make sure recovery completes properly. Signed-off-by: Neil Brown Signed-off-by: Greg Kroah-Hartman commit e116ec2ae0acf03d52459afeed259a449112b2b2 Author: Neil Brown Date: Thu Jul 3 02:45:35 2008 +0000 md: Don't acknowlege that stripe-expand is complete until it really is. commit efe311431869b40d67911820a309f9a1a41306f3 upstream We shouldn't acknowledge that a stripe has been expanded (When reshaping a raid5 by adding a device) until the moved data has actually been written out. However we are currently acknowledging (by calling md_done_sync) when the POST_XOR is complete and before the write. So track in s.locked whether there are pending writes, and don't call md_done_sync yet if there are. Note: we all set R5_LOCKED on devices which are are about to read from. This probably isn't technically necessary, but is usually done when writing a block, and justifies the use of s.locked here. This bug can lead to a crash if an array is stopped while an reshape is in progress. Signed-off-by: Neil Brown Signed-off-by: Greg Kroah-Hartman commit 583fe2db21978453aa522f56320f15b2de0d9d88 Author: Neil Brown Date: Thu Jul 3 02:45:30 2008 +0000 md: Fix error paths if md_probe fails. commit 9bbbca3a0ee09293108b67835c6bdf6196d7bcb3 upstream md_probe can fail (e.g. alloc_disk could fail) without returning an error (as it alway returns NULL). So when we call mddev_find immediately afterwards, we need to check that md_probe actually succeeded. This means checking that mdev->gendisk is non-NULL. Cc: Dave Jones Signed-off-by: Neil Brown Signed-off-by: Greg Kroah-Hartman commit 3cf5f2ed4231e64036fc8b80612e26efac0f53d4 Author: Divyesh Shah Date: Thu Jul 3 02:45:26 2008 +0000 block: Fix the starving writes bug in the anticipatory IO scheduler commit d585d0b9d73ed999cc7b8cf3cac4a5b01abb544e upstream AS scheduler alternates between issuing read and write batches. It does the batch switch only after all requests from the previous batch are completed. When switching to a write batch, if there is an on-going read request, it waits for its completion and indicates its intention of switching by setting ad->changed_batch and the new direction but does not update the batch_expire_time for the new write batch which it does in the case of no previous pending requests. On completion of the read request, it sees that we were waiting for the switch and schedules work for kblockd right away and resets the ad->changed_data flag. Now when kblockd enters dispatch_request where it is expected to pick up a write request, it in turn ends the write batch because the batch_expire_timer was not updated and shows the expire timestamp for the previous batch. This results in the write starvation for all the cases where there is the intention for switching to a write batch, but there is a previous in-flight read request and the batch gets reverted to a read_batch right away. This also holds true in the reverse case (switching from a write batch to a read batch with an in-flight write request). I've checked that this bug exists on 2.6.11, 2.6.18, 2.6.24 and linux-2.6-block git HEAD. I've tested the fix on x86 platforms with SCSI drives where the driver asks for the next request while a current request is in-flight. This patch is based off linux-2.6-block git HEAD. Bug reproduction: A simple scenario which reproduces this bug is: - dd if=/dev/hda3 of=/dev/null & - lilo The lilo takes forever to complete. This can also be reproduced fairly easily with the earlier dd and another test program doing msync(). The example test program below should print out a message after every iteration but it simply hangs forever. With this bugfix it makes forward progress. ==== Example test program using msync() (thanks to suleiman AT google DOT com) inline uint64_t rdtsc(void) { int64_t tsc; __asm __volatile("rdtsc" : "=A" (tsc)); return (tsc); } int main(int argc, char **argv) { struct stat st; uint64_t e, s, t; char *p, q; long i; int fd; if (argc < 2) { printf("Usage: %s \n", argv[0]); return (1); } if ((fd = open(argv[1], O_RDWR | O_NOATIME)) < 0) err(1, "open"); if (fstat(fd, &st) < 0) err(1, "fstat"); p = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); t = 0; for (i = 0; i < 1000; i++) { *p = 0; msync(p, 4096, MS_SYNC); s = rdtsc(); *p = 0; __asm __volatile(""::: "memory"); e = rdtsc(); if (argc > 2) printf("%d: %lld cycles %jd %jd\n", i, e - s, (intmax_t)s, (intmax_t)e); t += e - s; } printf("average time: %lld cycles\n", t / 1000); return (0); } Acked-by: Nick Piggin Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit da1be4d48515fde4eab98c776726747f7694f59f Author: Johannes Berg Date: Wed Jul 2 20:36:31 2008 -0500 mac80211: detect driver tx bugs When a driver rejects a frame in it's ->tx() callback, it must also stop queues, otherwise mac80211 can go into a loop here. Detect this situation and abort the loop after five retries, warning about the driver bug. This patch was added to mainline as commit ef3a62d272f033989e83eb1f26505f93f93e3e69. Thanks to Larry Finger for doing the -stable port. Cc: Larry Finger Signed-off-by: Johannes Berg Signed-off-by: David S. Miller commit 204b304df21a73cce2210eae236de6caaf3bc09b Author: Michael Buesch Date: Thu Jul 3 02:04:33 2008 +0200 b43: Fix possible MMIO access while device is down This fixes a possible MMIO access while the device is still down from a suspend cycle. MMIO accesses with the device powered down may cause crashes on certain devices. Upstream commit is 33598cf261e393f2b3349cb55509e358014bfd1f Signed-off-by: Michael Buesch Signed-off-by: Greg Kroah-Hartman commit bffce0fa10165b431dec4b727eae2d6e0cf5ddcf Author: Michael Buesch Date: Thu Jul 3 01:04:29 2008 +0200 b43: Do not return TX_BUSY from op_tx Never return TX_BUSY from op_tx. It doesn't make sense to return TX_BUSY, if we can not transmit the packet. Drop the packet and return TX_OK. This will fix the resume hang. Upstream commit is 66193a7cef2239bfd1b9b96e304770facf7a49c7 Signed-off-by: Michael Buesch Signed-off-by: Greg Kroah-Hartman commit da71a4347bcba891f568e3fb66c5916c953d4417 Author: Michael Buesch Date: Thu Jul 3 01:06:32 2008 +0200 b43legacy: Do not return TX_BUSY from op_tx Never return TX_BUSY from op_tx. It doesn't make sense to return TX_BUSY, if we can not transmit the packet. Drop the packet and return TX_OK. Upstream commit is eb803e419ca6be06ece2e42027bb4ebd8ec09f91 Signed-off-by: Michael Buesch Signed-off-by: Greg Kroah-Hartman