- 09 Oct, 2008 26 commits
-
-
Joel Becker authored
commit d6817cdb upstream The ocfs2_stack_driver_request() function failed to increment the refcount of an already-active stack. It only did the increment on the first reference. Whoops. Signed-off-by:
Joel Becker <joel.becker@oracle.com> Tested-by:
Marcos Matsunaga <marcos.matsunaga@oracle.com> Signed-off-by:
Mark Fasheh <mfasheh@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yinghai Lu authored
commit e0da3364 upstream x86: introduce max_physical_apicid for bigsmp switching a multi-socket test-system with 3 or 4 ioapics, when 4 dualcore cpus or 2 quadcore cpus installed, needs to switch to bigsmp or physflat. CPU apic id is [4,11] instead of [0,7], and we need to check max apic id instead of cpu numbers. also add check for 32 bit when acpi is not compiled in or acpi=off. Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Balbir Singh authored
commit 49048622 upstream Spencer reported a problem where utime and stime were going negative despite the fixes in commit b27f03d4. The suspected reason for the problem is that signal_struct maintains it's own utime and stime (of exited tasks), these are not updated using the new task_utime() routine, hence sig->utime can go backwards and cause the same problem to occur (sig->utime, adds tsk->utime and not task_utime()). This patch fixes the problem TODO: using max(task->prev_utime, derived utime) works for now, but a more generic solution is to implement cputime_max() and use the cputime_gt() function for comparison. Reported-by: spencer@bluehost.com Signed-off-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Jens Axboe authored
commit 48fd4f93 upstream Reported by Milan Broz <mbroz@redhat.com>, commit 18ce3751 inadvertently made submit_bh() discard the barrier bit for a WRITE_SYNC request. Fix that up. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Zachary Amsden authored
commit de59985e upstream After investigating a JRE failure, I found this bug was introduced a long time ago, and had already managed to survive another bugfix which occurred on the same line. The result is a total failure of the JRE due to LDT selectors not working properly. This one took a long time to rear up because LDT usage is not very common, but the bug is quite serious. It got introduced along with another bug, already fixed, by 75b8bb3eSigned-off-by:
Zachary Amsden <zach@vmware.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Glauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Suresh Siddha authored
[Upstream commit: 6ffac1e9] On Thu, Jul 24, 2008 at 03:43:44PM -0700, Linus Torvalds wrote: > So how about this patch as a starting point? This is the RightThing(tm) to > do regardless, and if it then makes it easier to do some other cleanups, > we should do it first. What do you think? restore_fpu_checking() calls init_fpu() in error conditions. While this is wrong(as our main intention is to clear the fpu state of the thread), this was benign before commit 92d140e2 ("x86: fix taking DNA during 64bit sigreturn"). Post commit 92d140e2, live FPU registers may not belong to this process at this error scenario. In the error condition for restore_fpu_checking() (especially during the 64bit signal return), we are doing init_fpu(), which saves the live FPU register state (possibly belonging to some other process context) into the thread struct (through unlazy_fpu() in init_fpu()). This is wrong and can leak the FPU data. For the signal handler restore error condition in restore_i387(), clear the fpu state present in the thread struct(before ultimately sending a SIGSEGV for badframe). For the paranoid error condition check in math_state_restore(), send a SIGSEGV, if we fail to restore the state. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
[ Upstream commit b30f3ae5] Suresh Siddha wants to fix a possible FPU leakage in error conditions, but the fact that save/restore_i387() are inlines in a header file makes that harder to do than necessary. So start off with an obvious cleanup. This just moves the x86-64 version of save/restore_i387() out of the header file, and moves it to the only file that it is actually used in: arch/x86/kernel/signal_64.c. So exposing it in a header file was wrong to begin with. [ Side note: I'd like to fix up some of the games we play with the 32-bit version of these functions too, but that's a separate matter. The 32-bit versions are shared - under different names at that! - by both the native x86-32 code and the x86-64 32-bit compatibility code ] Acked-by:
-
Joerg Roedel authored
(cherry picked from commit e5eab0ce) Accesses to CR4 are intercepted even with Nested Paging enabled. But the code does not check if the guest wants to do a global TLB flush. So this flush gets lost. This patch adds the check and the flush to svm_set_cr4. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Joerg Roedel authored
(cherry picked from commit 44874f84) This patch introduces a guest TLB flush on every NPF exit in KVM. This fixes random segfaults and #UD exceptions in the guest seen under some workloads (e.g. long running compile workloads or tbench). A kernbench run with and without that fix showed that it has a slowdown lower than 0.5% Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Takashi Iwai authored
Upstream-commit-id: 24e8fc49 The power_mutex lock in snd_pcm_drop may cause a possible deadlock chain, and above all, it's unneeded. Let's get rid of it. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
Upstream-commit-id: 399ccdc1 The PCM and rawmidi open callbacks have a lock against card->controls_list but it takes a wrong one, card->controls_rwsem, instead of a right one card->ctl_files_rwlock. This patch fixes them. This change also fixes automatically the potential deadlocks due to mm->mmap_sem in munmap and copy_from/to_user, reported by Sitsofe Wheeler: A: snd_ctl_elem_user_tlv(): card->controls_rwsem => mm->mmap_sem B: snd_pcm_open(): card->open_mutex => card->controls_rwsem C: munmap: mm->mmap_sem => snd_pcm_release(): card->open_mutex The patch breaks the chain. Signed-off-by:
-
Clemens Ladisch authored
Upstream-commit-id: df91bc23 When changing the sample rate, the CMI8788's master clock output becomes unstable for a short time. The AK4396 needs the master clock to do SPI writes, so writing to an AK4396 control register directly after a sample rate change will garble the value. In our case, this leads to the DACs being misconfigured to I2S sample format, which results in a wrong output level and horrible distortions on samples louder than -6 dB. To fix this, we need to wait until the new master clock signal has become stable before doing SPI writes. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Takashi Iwai authored
commit 24918b61 upstream Dell Inspiron 1525 seems to have a buggy BIOS setup and screws up the recent codec parser, as reported by Oleksandr Natalenko: http://lkml.org/lkml/2008/9/12/203 This patch adds the working model, dell-3stack, statically. Signed-off-by:
-
Andrew Vasquez authored
commit 048feec5 upstream Josip Rodin noted (http://article.gmane.org/gmane.linux.ports.sparc/10152) the driver oopsing during registration of an rport to the FC-transport layer with a backtrace indicating a dereferencing of an shost->shost_data equal to NULL. David Miller identified a small window in driver logic where this could happen: > Look at how the driver registers the IRQ handler before the host has > been registered with the SCSI layer. > > That leads to a window of time where the shost hasn't been setup > fully, yet ISRs can come in and trigger DPC thread events, such as > loop resyncs, which expect the transport area to be setup. > > But it won't be setup, because scsi_add_host() hasn't finished yet. > > Note that in Josip's crash log, we don't even see the > > qla_printk(KERN_INFO, ha, "\n" > " QLogic Fibre Channel HBA Driver: %s\n" > " QLogic %s - %s\n" > " ISP%04X: %s @ %s hdma%c, host#=%ld, fw=%s\n", > ... > > message yet. > > Which means that the crash occurs between qla2x00_request_irqs() > and printing that message. Close this window by enabling RISC interrupts after the host has been registered with the SCSI midlayer. Reported-by:
Josip Rodin <joy@entuzijast.net> Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Geoff Levand authored
commit 83a79820 upstream Commit de85422b, 'USB: fix interrupt disabling for HCDs with shared interrupt handlers' changed usb_add_hcd() to strip IRQF_DISABLED from irqflags prior to calling request_irq() with the justification that such a removal was necessary for shared interrupts to work properly. Unfortunately, the change in that commit unconditionally removes the IRQF_DISABLED flag, causing problems on platforms that don't use a shared interrupt but require IRQF_DISABLED. This change adds a check for IRQF_SHARED prior to removing the IRQF_DISABLED flag. Fixes the PS3 system startup hang reported with recent Fedora and OpenSUSE kernels. Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig), as local_irq_enable_in_hardirq() is defined as a null statement for that config. Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Stefan Becker <Stefan.Becker@nokia.com> Signed-off-by:
-
Kirill A. Shutemov authored
commit c32a162f upstream linux/time.h conflicts with time.h from glibc It breaks building smbmount from samba. It's regression introduced by commit 76308da1 (" smb.h: uses struct timespec but didn't include linux/time.h"). Signed-off-by:
Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Mike Rapoport authored
commit 20b918dc upstream This patch fixes a build error in the pxa2xx-spi driver, introduced by commit 7e964455 ("pxa2xx_spi: dma bugfixes") CC drivers/spi/pxa2xx_spi.o drivers/spi/pxa2xx_spi.c: In function 'map_dma_buffers': drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary & drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary & drivers/spi/pxa2xx_spi.c: In function 'pump_transfers': drivers/spi/pxa2xx_spi.c:897: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int' [dbrownell@users.sourceforge.net: fix warning too ] Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Acked-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Ned Forrester authored
commit 8423597d upstream Fixes several chipselect bugs in the pxa2xx_spi driver. These bugs are in all versions of this driver and prevent using it with chips like m25p16 flash. 1. The spi_transfer.cs_change flag is handled too early: before spi_transfer.delay_usecs applies, thus making the delay ineffective at holding chip select. 2. spi_transfer.delay_usecs is ignored on the last transfer of a message (likewise not holding chipselect long enough). 3. If spi_transfer.cs_change is set on the last transfer, the chip select is always disabled, instead of the intended meaning: optionally holding chip select enabled for the next message. Those first three bugs were fixed with a relocation of delays and chip select de-assertions. 4. If a message has the cs_change flag set on the last transfer, and had the chip select stayed enabled as requested (see 3, above), it would not have been disabled if the next message is for a different chip. Fixed by dropping chip select regardless of cs_change at end of a message, if there is no next message or if the next message is for a different chip. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by:
Ned Forrester <nforrester@whoi.edu> Cc: Vernon Sauder <vernoninhand@gmail.com> Cc: Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Ned Forrester authored
commit 7e964455 upstream Fixes two DMA bugs in the pxa2xx_spi driver. The first bug is in all versions of this driver; the second was introduced in the 2.6.20 kernel, and prevents using the driver with chips like m25p16 flash (which can issue large DMA reads). 1. Zero length transfers are permitted for use to insert timing, but pxa2xx_spi.c will fail if this is requested in DMA mode. Fixed by using programmed I/O (PIO) mode for such transfers. 2. Transfers larger than 8191 are not permitted in DMA mode. A test for length rejects all large transfers regardless of DMA or PIO mode. Worked around by rejecting only large transfers with DMA mapped buffers, and forcing all other transfers larger than 8191 to use PIO mode. A rate limited warning is issued for DMA transfers forced to PIO mode. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by:
-
Mel Gorman authored
commit 5bead2a0 upstream The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when scanning zonelists to keep track of where in the zonelist it is. The zoneref that is returned corresponds to the the next zone that is to be scanned, not the current one. It was intended to be treated as an opaque list. When the page allocator is scanning a zonelist, it marks elements in the zonelist corresponding to zones that are temporarily full. As the zonelist is being updated, it uses the cursor here; if (NUMA_BUILD) zlc_mark_zone_full(zonelist, z); This is intended to prevent rescanning in the near future but the zoneref cursor does not correspond to the zone that has been found to be full. This is an easy misunderstanding to make so this patch corrects the problem by changing zoneref cursor to be the current zone being scanned instead of the next one. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Cc: Andy Whitcroft <apw@shadowen.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Yuri Tikhonov authored
commit de24125d upstream Should clear the next pointer of the TX if we are sure that the next TX (say NXT) will be submitted to the channel too. Overwise, we break the chain of descriptors, because we lose the information about the next descriptor to run. So next time, when invoke async_tx_run_dependencies() with TX, it's TX->next will be NULL, and NXT will be never submitted. Signed-off-by:
Yuri Tikhonov <yur@emcraft.com> Signed-off-by:
Ilya Yanok <yanok@emcraft.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Andrew Morton authored
commit 70bb0896 upstream mmc_block_open() increments md->usage although it returns with -EROFS when default mounting a MMC/SD card with write protect switch on. This reference counting bug prevents /dev/mmcblkX from being released on card removal, and situation worsen with reinsertion until the minor number range runs out. Reported-by: <sasin@solomon-systech.com> Acked-by:
Pierre Ossman <drzeus-list@drzeus.cx> Signed-off-by:
-
Andy Gospodarek authored
commit 15e79f24 upstream This commit dropped the setting of the default interrupt throttle rate. commit 021230d4 Author: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com> Date: Mon Mar 3 15:03:45 2008 -0800 ixgbe: Introduce MSI-X queue vector code The following patch adds it back. Without this the default value of 0 causes the performance of this card to be awful. Restoring these to the default values yields much better performance. This regression has been around since 2.6.25. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Sven Wegener authored
In Linus' tree: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commit;h=e74783ec3cb981211689bd2cfd3248f8dc48ec01 We need to convert the error pointer from class_create(), else we'll return the successful return code from register_chrdev() on failure. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Milan Broz authored
commit 9f497bcc upstream ACPI: Fix thermal shutdowns Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Chuck Ebbert authored
This patch is not needed in 2.6.27 because it has new c1e-aware idle code. In kernel 2.6.26 the 32-bit x86 timers are started earlier than before. This breaks AMD c1e detection trying to force timer broadcast for the local apic timer. Copy the code from the 64-bit kernel to force timer broadcast late. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=11427Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 08 Sep, 2008 14 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This resolves the build error introduced in 97348238 due to Greg applying the the incorrect patch. Thanks to Randy Dunlap for reporting this. Tested-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Tejun Heo authored
commit 4bdee6c5 upstream sata_mv allowed issuing two DMA commands concurrently which the hardware allows. Unfortunately, libata core layer isn't ready for this yet and spews ugly warning message and malfunctions on this. Don't allow concurrent DMA commands for now. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Avi Kivity authored
(cherry picked from commit cd5998eb) The shadow code assigns a pte directly in one place, which is nonatomic on i386 can can cause random memory references. Fix by using an atomic setter. Signed-off-by:
-
Ingo Molnar authored
commit 9754a5b8 upstream x86: work around MTRR mask setting, v2 improve the debug printout: - make it actually display something - print it only once would be nice to have a WARN_ONCE() facility, to feed such things to kerneloops.org. Signed-off-by:
-
J. Bruce Fields authored
commit 91b80969 upstream The array we kmalloc() here is not large enough. Thanks to Johann Dahm and David Richter for bug report and testing. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Cc: David Richter <richterd@citi.umich.edu> Tested-by:
Johann Dahm <jdahm@umich.edu> Signed-off-by:
-
Cyrill Gorcunov authored
commit 27df6f25 upstream Vegard Nossum reported ---------------------- > I noticed that something weird is going on with /proc/sys/sunrpc/transports. > This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When > I "cat" this file, I get the expected output: > $ cat /proc/sys/sunrpc/transports > tcp 1048576 > udp 32768 > But I think that it does not check the length of the buffer supplied by > userspace to read(). With my original program, I found that the stack was > being overwritten by the characters above, even when the length given to > read() was just 1. David Wagner added (among other things) that copy_to_user could be probably used here. Ingo Oeser suggested to use simple_read_from_buffer() here. The conclusion is that proc_do_xprt doesn't check for userside buffer size indeed so fix this by using Ingo's suggestion. Reported-by:
Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> CC: Ingo Oeser <ioe-lkml@rameria.de> Cc: Neil Brown <neilb@suse.de> Cc: Chuck Lever <chuck.lever@oracle.com> Cc: Greg Banks <gnb@sgi.com> Cc: Tom Tucker <tom@opengridcomputing.com> Signed-off-by:
-
Francois Romieu authored
commit a866bbf6 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Tested-by:
Alistair John Strachan <alistair@devzero.co.uk> Tested-by:
Timothy J Fontaine <tjfontaine@atxconsulting.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by:
-
Matt Carlson authored
patch 4ba526ce upstream The git commit 7c5026aa ("tg3: Add link state reporting to UMP firmware") introduced code that waits for previous firmware events to be serviced before attempting to submit a new event. Unfortunately that patch contained a bug that cause the driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended. This patch fixes that bug. This bug revealed that not all firmware versions service driver events though. Since we do not know which versions of the firmware do and don't service these events, the driver needs some way to minimize the effects of the delay. This patch solves the problem by recording a jiffies timestamp when it submits an event to the hardware. If the jiffies counter shows that 2.5 milliseconds have already passed, a wait is not needed and the driver can proceed to submit a new event. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Herbert Xu authored
crypto: authenc - Avoid using clobbered request pointer [ Upstream commit: a697690b ] Authenc works in two stages for encryption, it first encrypts and then computes an ICV. The context memory of the request is used by both operations. The problem is that when an asynchronous encryption completes, we will compute the ICV and then reread the context memory of the encryption to get the original request. It just happens that we have a buffer of 16 bytes in front of the request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger the bug. However, any attempt to uses a larger ICV instantly kills the machine when the first asynchronous encryption is completed. This patch fixes this by saving the request pointer before we start the ICV computation. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David S. Miller authored
[ Upstream commit f2b60794 ] First, lmb_enforce_memory_limit() interprets it's argument (mostly, heh) as a size limit not an address limit. So pass the raw cmdline_memory_size value into it. And we don't need to check it against zero, lmb_enforce_memory_limit() does that for us. Next, free_initmem() needs special handling when the kernel command line trims the available memory. The problem case is if the trimmed out memory is where the kernel image itself resides. When that memory is trimmed out, we don't add those physical ram areas to the sparsemem active ranges, amongst other things. Which means that this free_initmem() code will free up invalid page structs, resulting in either crashes or hangs. Just quick fix this by not freeing initmem at all if "mem=" was given on the boot command line. Signed-off-by:
-
David S. Miller authored
[ Upstream commit c918dcce ] If 'start' does not begin on a page boundary, we can overshoot past 'end'. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 37b08e34 ] Ever since commit 4c563f76 ("[XFRM]: Speed up xfrm_policy and xfrm_state walking") it is illegal to call __xfrm_state_destroy (and thus xfrm_state_put()) with xfrm_state_lock held. If we do, we'll deadlock since we have the lock already and __xfrm_state_destroy() tries to take it again. Fix this by pushing the xfrm_state_put() calls after the lock is dropped. Signed-off-by:
-
