- Jul 24, 2008
-
-
Greg Kroah-Hartman authored
-
Alexander Simon authored
commit dc88807e 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 <pb@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Ludwig Nussel <lnussel@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Steven Rostedt authored
commit ee3ece83 upstream. Due to a possible deadlock, the waking of the softirq was pushed outside of the hrtimer base locks. See commit 0c96c597 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 <srostedt@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Pierre Ossman authored
commit bf5b1935 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 <drzeus@drzeus.cx> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Karl Beldan authored
commit 4fe16897 upstream Signed-off-by: Karl Beldan <karl.beldan@gmail.com> Acked-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Philipp Zabel authored
commit 97f8571e 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 <philipp.zabel@gmail.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Vitaly Bordug authored
commit ba0fc709 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 <vitb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Herbert Xu authored
Upstream commit: 872ac874 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 <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
James Bottomley authored
commit 081a5bcb 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 <Eric.Moore@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Darren Jenkins authored
commit 43f77e91 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 <darrenrjenkins@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz> 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>
-
Darren Jenkins authored
commit 4fc89e39 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 <darrenrjenkins@gmail.com> Acked-by: Karsten Keil <kkeil@suse.de> 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>
-
Jaya Kumar authored
commit f31ad92f 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 <jayakumar.lkml@gmail.com> Cc: Bernard Blackham <bernard@largestprime.net> 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>
-
Eric W. Biederman authored
commit 05d81d22 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 <ebiederm@xmission.com> Acked-by: Alan Cox <alan@redhat.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>
-
Andres Salomon authored
commit bca5c2c5 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 <csetlow@tower-research.com> Signed-off-by: Andres Salomon <dilinger@debian.org> Acked-by: Jonathan Corbet <corbet@lwn.net> 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>
-
Jeff Layton authored
commit 536abdb0 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 <jlayton@redhat.com> Cc: Steven French <sfrench@us.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>
-
Marcin Obara authored
commit fb0e7e11 upstream This patch adds Intel TPM TIS device HID: ICO0102 Signed-off-by: Marcin Obara <marcin_obara@users.sourceforge.net> Acked-by: Marcel Selhorst <tpm@selhorst.net> Acked-by: Rajiv Andrade <srajiv@linux.vnet.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>
-
Eugene Surovegin authored
commit a7de3902 upstream Fix RapidIO device reference counting. Signed-of-by: Eugene Surovegin <ebs@ebshome.net> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Paul Gortmaker authored
commit 61ca9daa 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 <paul.gortmaker@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Brownell <david-b@pacbell.net> Cc: Thomas Gleixner <tglx@linutronix.de> 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>
-
Dmitry Adamushko authored
commit bdb21928 upstream Vegard Nossum reported a crash in kmem_cache_alloc(): BUG: unable to handle kernel paging request at da87d000 IP: [<c01991c7>] 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:[<c01991c7>] 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 <dmitry.adamushko@gmail.com> Reported-by: Vegard Nossum <vegard.nossum@gmail.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Hugh Dickins authored
commit 96a8e13e 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 <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Firat Birlik authored
Commit 9dfd5500 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 <dsd@gentoo.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Peter Nixon <listuser@peternixon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jozsef Kadlecsik authored
Upstream commit 84ebe1cd : 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 <kadlec@blackhole.kfki.hu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joonwoo Park authored
Upstream commit aebb6a84 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 <joonwpark81@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Williams authored
commit 7a1fc53c 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 <dan.j.williams@intel.com> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Will Newton authored
commit f15e3973 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 <will.newton@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Oliver Hartkopp authored
commit 7f2d38eb 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 <oliver.hartkopp@volkswagen.de> Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de> Acked-by: Andre Naujoks <nautsch@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Guennadi Liakhovetski authored
commit 7ca796f4 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 <g.liakhovetski@gmx.de> Tested-by: Vipul Gandhi <vcgandhi1@aol.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> 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>
-
Mike Miller authored
commit 49153998 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 <mike.miller@hp.com> Cc: Jens Axboe <jens.axboe@oracle.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>
-
Jeff Mahoney authored
commit eb35c218 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 <jeffm@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Blackwood authored
commit 2d5c1be8 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 <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Matthew Wilcox authored
commit c95e62ce upstream Timeouts are measured in jiffies, not in seconds. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
James Bottomley authored
commit ec5e69f6 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 <davem@davemloft.net> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David S. Miller authored
commit eadc49b1 upstream OOPS reported by Friedrich Oslage <bluebird@porno-bullen.de> 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 <davem@davemloft.net> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Ingo Molnar authored
commit c5643cab upstream Original Author: Michael Buesch <mb@bu3sch.de> 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 [<c0125ecf>] warn_on_slowpath+0x4f/0x70 [<c0126834>] ? release_console_sem+0x1b4/0x1d0 [<c0126d00>] ? vprintk+0x2a0/0x450 [<c012fde5>] ? __mod_timer+0xa5/0xc0 [<c046f7fd>] ? mdio_sync+0x3d/0x50 [<c0160ef6>] ? marker_probe_cb+0x46/0xa0 [<c0126ed7>] ? printk+0x27/0x50 [<c046f4c3>] ? vortex_set_duplex+0x43/0xc0 [<c046f521>] ? vortex_set_duplex+0xa1/0xc0 [<c0471b92>] ? vortex_timer+0xe2/0x3e0 [<c012b361>] local_bh_enable_ip+0xd1/0xe0 [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40 [<c0471b92>] vortex_timer+0xe2/0x3e0 [<c014743b>] ? trace_hardirqs_on+0xb/0x10 [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160 [<c012f8b2>] run_timer_softirq+0x162/0x1c0 [<c0471ab0>] ? vortex_timer+0x0/0x3e0 [<c012b361>] local_bh_enable_ip+0xd1/0xe0 [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40 [<c0471b92>] vortex_timer+0xe2/0x3e0 [<c014743b>] ? trace_hardirqs_on+0xb/0x10 [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160 [<c012f8b2>] run_timer_softirq+0x162/0x1c0 [<c0471ab0>] ? vortex_timer+0x0/0x3e0 [<c0471ab0>] ? vortex_timer+0x0/0x3e0 [<c012b60a>] __do_softirq+0x9a/0x160 [<c012b570>] ? __do_softirq+0x0/0x160 [<c0106775>] call_on_stack+0x15/0x30 [<c012b4f5>] ? irq_exit+0x55/0x60 [<c0106e85>] ? do_IRQ+0x85/0xd0 [<c0147391>] ? trace_hardirqs_on_caller+0xc1/0x160 [<c0104888>] ? common_interrupt+0x28/0x30 [<c08d8ac8>] ? mutex_unlock+0x8/0x10 [<c08d8180>] ? _cond_resched+0x10/0x30 [<c07a3be7>] ? netpoll_setup+0x117/0x390 [<c0cbfcfe>] ? init_netconsole+0x14e/0x1b0 [<c013d539>] ? ktime_get+0x19/0x40 [<c0c9bab2>] ? kernel_init+0x1b2/0x2c0 [<c0cbfbb0>] ? init_netconsole+0x0/0x1b0 [<c0396aa4>] ? trace_hardirqs_on_thunk+0xc/0x10 [<c0103f12>] ? restore_nocheck_notrace+0x0/0xe [<c0c9b900>] ? kernel_init+0x0/0x2c0 [<c0c9b900>] ? kernel_init+0x0/0x2c0 [<c0104aa7>] ? 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 <mingo@elte.hu> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Buesch authored
commit 2f9ec47d 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 <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
maximilian attems authored
commit 292d7355 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 <ubuntu@hjernemadsen.org> Cc: Chuck Short <zulcss@ubuntu.com> Cc: Jean Delvare <khali@linux-fr.org> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: maximilian attems <max@stro.at> Cc: Mark M. Hoffman <mhoffman@lightlink.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>
-
Stefan Becker authored
commit de85422b 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 <stefan.becker@nokia.com> Acked-by: David Brownell <david-b@pacbell.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
commit 29c8f6a7 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 <dbrownell@users.sourceforge.net> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
commit 056761e5 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 <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Dooks authored
commit 3ee38d8b 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 <ben-linux@fluff.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-