aboutsummaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAge
* ARM: shmobile: r8a73a4: Fix resources for SCIFB0Takanari Hayama2013-07-21
| | | | | | | | | | | | | | | | | commit f820b60582f75e73e83b8505d7e48fe59770f558 upstream. Fix base address and IRQ resources associated with SCIFB0. This bug was introduced by e481a528901d0cd18b5b5fcbdc55207ea3b6ef68 ("ARM: shmobile: r8a73a4 SCIF support V3") which was included in v3.10. Signed-off-by: Takanari Hayama <taki@igel.co.jp> Acked-by: Magnus Damm <damm@opensource.se> [ horms+renesas@verge.net.au: Add information about commit and version this bug was added in ] Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: dts: imx: cpus/cpu nodes dts updatesLorenzo Pieralisi2013-07-21
| | | | | | | | | | | | commit 7925e89f54fc49bcd1e73f0a65c4a3eb35b9cfb1 upstream. This patch updates the in-kernel dts files according to the latest cpus and cpu bindings updates for ARM. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUsJason Liu2013-07-21
| | | | | | | | | | | | | | | | | | | | | | commit cbbe6f82b489e7ceba4ad7c833bd3a76cd0084cb upstream. When the local timer freq changed, the twd_update_frequency function should be run all the CPUs include itself, otherwise, the twd freq will not get updated and the local timer will not run correcttly. smp_call_function will run functions on all other CPUs, but not include himself, this is not correct,use on_each_cpu instead to fix this issue. Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Jason Liu <r64343@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7769/1: Cortex-A15: fix erratum 798181 implementationMarc Zyngier2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | commit 0d0752bca1f9a91fb646647aa4abbb21156f316c upstream. Looking into the active_asids array is not enough, as we also need to look into the reserved_asids array (they both represent processes that are currently running). Also, not holding the ASID allocator lock is racy, as another CPU could schedule that process and trigger a rollover, making the erratum workaround miss an IPI. Exposing this outside of context.c is a little ugly on the side, so let's define a new entry point that the erratum workaround can call to obtain the cpumask. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7768/1: prevent risks of out-of-bound access in ASID allocatorMarc Zyngier2013-07-21
| | | | | | | | | | | | | | | | | | | | | commit b8e4a4740fa2b17c0a447b3ab783b3dc10702e27 upstream. On a CPU that never ran anything, both the active and reserved ASID fields are set to zero. In this case the ASID_TO_IDX() macro will return -1, which is not a very useful value to index a bitmap. Instead of trying to offset the ASID so that ASID #1 is actually bit 0 in the asid_map bitmap, just always ignore bit 0 and start the search from bit 1. This makes the code a bit more readable, and without risk of OoB access. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7767/1: let the ASID allocator handle suspended animationMarc Zyngier2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ae120d9edfe96628f03d87634acda0bfa7110632 upstream. When a CPU is running a process, the ASID for that process is held in a per-CPU variable (the "active ASIDs" array). When the ASID allocator handles a rollover, it copies the active ASIDs into a "reserved ASIDs" array to ensure that a process currently running on another CPU will continue to run unaffected. The active array is zero-ed to indicate that a rollover occurred. Because of this mechanism, a reserved ASID is only remembered for a single rollover. A subsequent rollover will completely refill the reserved ASIDs array. In a severely oversubscribed environment where a CPU can be prevented from running for extended periods of time (think virtual machines), the above has a horrible side effect: [P{a} denotes process P running with ASID a] CPU-0 CPU-1 A{x} [active = <x 0>] [suspended] runs B{y} [active = <x y>] [rollover: active = <0 0> reserved = <x y>] runs B{y} [active = <0 y> reserved = <x y>] [rollover: active = <0 0> reserved = <0 y>] runs C{x} [active = <0 x>] [resumes] runs A{x} At that stage, both A and C have the same ASID, with deadly consequences. The fix is to preserve reserved ASIDs across rollovers if the CPU doesn't have an active ASID when the rollover occurs. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Catalin Carinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7765/1: perf: Record the user-mode PC in the call chain.Jed Davis2013-07-21
| | | | | | | | | | | | | | | | | commit c5f927a6f62196226915f12194c9d0df4e2210d7 upstream. With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip. It's possible to partially work around this problem by post-processing the data to use the PERF_SAMPLE_IP value, but this works only if the CPU wasn't in the kernel when the sample was taken. Signed-off-by: Jed Davis <jld@mozilla.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arch: c6x: mm: include "asm/uaccess.h" to pass compilingChen Gang2013-07-21
| | | | | | | | | | | | | | | | | | | commit fe74650166dd6905b0cf66594eb79222dc9d7109 upstream. Need include "asm/uaccess.h" to pass compiling. The related error (with allmodconfig): arch/c6x/mm/init.c: In function `paging_init': arch/c6x/mm/init.c:46:2: error: implicit declaration of function `set_fs' [-Werror=implicit-function-declaration] arch/c6x/mm/init.c:46:9: error: `KERNEL_DS' undeclared (first use in this function) arch/c6x/mm/init.c:46:9: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Chen Gang <gang.chen@asianux.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@linuxfoundation.org>
* xen/time: remove blocked time accounting from xen "clockchip"Laszlo Ersek2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0b0c002c340e78173789f8afaa508070d838cf3d upstream. ... because the "clock_event_device framework" already accounts for idle time through the "event_handler" function pointer in xen_timer_interrupt(). The patch is intended as the completion of [1]. It should fix the double idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to stolen time accounting (the removed code seems to be isolated). The approach may be completely misguided. [1] https://lkml.org/lkml/2011/10/6/10 [2] http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01068.html John took the time to retest this patch on top of v3.10 and reported: "idle time is correctly incremented for pv and hvm for the normal case, nohz=off and nohz=idle." so lets put this patch in. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: John Haxby <john.haxby@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86, efi: retry ExitBootServices() on failureZach Bobroff2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d3768d885c6ccbf8a137276843177d76c49033a7 upstream. ExitBootServices is absolutely supposed to return a failure if any ExitBootServices event handler changes the memory map. Basically the get_map loop should run again if ExitBootServices returns an error the first time. I would say it would be fair that if ExitBootServices gives an error the second time then Linux would be fine in returning control back to BIOS. The second change is the following line: again: size += sizeof(*mem_map) * 2; Originally you were incrementing it by the size of one memory map entry. The issue here is all related to the low_alloc routine you are using. In this routine you are making allocations to get the memory map itself. Doing this allocation or allocations can affect the memory map by more than one record. [ mfleming - changelog, code style ] Signed-off-by: Zach Bobroff <zacharyb@ami.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* parisc: optimize mtsp(0,sr) inline assemblyHelge Deller2013-07-21
| | | | | | | | | | | commit 92b59929825d67db575043a76651865d16873b36 upstream. If the value which should be moved into a space register is zero, we can optimize the inline assembly to become "mtsp %r0,%srX". Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* parisc: Ensure volatile space register %sr1 is not clobberedJohn David Anglin2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | commit e8d8fc219f9a0e63e7fb927881e6f4db8e7d34df upstream. I still see the occasional random segv on rp3440. Looking at one of these (a code 15), it appeared the problem must be with the cache handling of anonymous pages. Reviewing this, I noticed that the space register %sr1 might be being clobbered when we flush an anonymous page. Register %sr1 is used for TLB purges in a couple of places. These purges are needed on PA8800 and PA8900 processors to ensure cache consistency of flushed cache lines. The solution here is simply to move the %sr1 load into the TLB lock region needed to ensure that one purge executes at a time on SMP systems. This was already the case for one use. After a few days of operation, I haven't had a random segv on my rp3440. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* parisc: Fix gcc miscompilation in pa_memcpy()Helge Deller2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5b879d78bc0818aa710f5d4d9abbfc2aca075cc3 upstream. When running the LTP testsuite one may hit this kernel BUG() with the write06 testcase: kernel BUG at mm/filemap.c:2023! CPU: 1 PID: 8614 Comm: writev01 Not tainted 3.10.0-rc7-64bit-c3000+ #6 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e6e84 00000000401e6e88 IIR: 03ffe01f ISR: 0000000010340000 IOR: 000001fbe0380820 CPU: 1 CR30: 00000000bef80000 CR31: ffffffffffffffff ORIG_R28: 00000000bdc192c0 IAOQ[0]: iov_iter_advance+0x3c/0xc0 IAOQ[1]: iov_iter_advance+0x40/0xc0 RP(r2): generic_file_buffered_write+0x204/0x3f0 Backtrace: [<00000000401e764c>] generic_file_buffered_write+0x204/0x3f0 [<00000000401eab24>] __generic_file_aio_write+0x244/0x448 [<00000000401eadc0>] generic_file_aio_write+0x98/0x150 [<000000004024f460>] do_sync_readv_writev+0xc0/0x130 [<000000004025037c>] compat_do_readv_writev+0x12c/0x340 [<00000000402505f8>] compat_writev+0x68/0xa0 [<0000000040251d88>] compat_SyS_writev+0x98/0xf8 Reason for this crash is a gcc miscompilation in the fault handlers of pa_memcpy() which return the fault address instead of the copied bytes. Since this seems to be a generic problem with gcc-4.7.x (and below), it's better to simplify the fault handlers in pa_memcpy to avoid this problem. Here is a simple reproducer for the problem: int main(int argc, char **argv) { int fd, nbytes; struct iovec wr_iovec[] = { { "TEST STRING ",32}, { (char*)0x40005000,32} }; // random memory. fd = open(DATA_FILE, O_RDWR | O_CREAT, 0666); nbytes = writev(fd, wr_iovec, 2); printf("return value = %d, errno %d (%s)\n", nbytes, errno, strerror(errno)); return 0; } In addition, John David Anglin wrote: There is no gcc PR as pa_memcpy is not legitimate C code. There is an implicit assumption that certain variables will contain correct values when an exception occurs and the code randomly jumps to one of the exception blocks. There is no guarantee of this. If a PR was filed, it would likely be marked as invalid. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* KVM: VMX: mark unusable segment as nonpresentGleb Natapov2013-07-13
| | | | | | | | | | | | | | | | | commit 03617c188f41eeeb4223c919ee7e66e5a114f2c6 upstream. Some userspaces do not preserve unusable property. Since usable segment has to be present according to VMX spec we can use present property to amend userspace bug by making unusable segment always nonpresent. vmx_segment_access_rights() already marks nonpresent segment as unusable. Reported-by: Stefan Pietsch <stefan.pietsch@lsexperts.de> Tested-by: Stefan Pietsch <stefan.pietsch@lsexperts.de> Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* powerpc/eeh: Fix fetching bus for single-dev-PEGavin Shan2013-06-30
| | | | | | | | | | | | While running Linux as guest on top of phyp, we possiblly have PE that includes single PCI device. However, we didn't return its PCI bus correctly and it leads to failure on recovery from EEH errors for single-dev-PE. The patch fixes the issue. Cc: <stable@vger.kernel.org> # v3.7+ Cc: Steve Best <sbest@us.ibm.com> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* Merge branch 'merge' of ↵Linus Torvalds2013-06-29
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc fixes from Ben Herrenschmidt: "We discovered some breakage in our "EEH" (PCI Error Handling) code while doing error injection, due to a couple of regressions. One of them is due to a patch (37f02195bee9 "powerpc/pci: fix PCI-e devices rescan issue on powerpc platform") that, in hindsight, I shouldn't have merged considering that it caused more problems than it solved. Please pull those two fixes. One for a simple EEH address cache initialization issue. The other one is a patch from Guenter that I had originally planned to put in 3.11 but which happens to also fix that other regression (a kernel oops during EEH error handling and possibly hotplug). With those two, the couple of test machines I've hammered with error injection are remaining up now. EEH appears to still fail to recover on some devices, so there is another problem that Gavin is looking into but at least it's no longer crashing the kernel." * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/pci: Improve device hotplug initialization powerpc/eeh: Add eeh_dev to the cache during boot
| * powerpc/pci: Improve device hotplug initializationGuenter Roeck2013-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc platform) fixes a problem with interrupt and DMA initialization on hot plugged devices. With this commit, interrupt and DMA initialization for hot plugged devices is handled in the pci device enable function. This approach has a couple of drawbacks. First, it creates two code paths for device initialization, one for hot plugged devices and another for devices known during the initial PCI scan. Second, the initialization code for hot plugged devices is only called when the device is enabled, ie typically in the probe function. Also, the platform specific setup code is called each time pci_enable_device() is called, not only once during device discovery, meaning it is actually called multiple times, once for devices discovered during the initial scan and again each time a driver is re-loaded. The visible result is that interrupt pins are only assigned to hot plugged devices when the device driver is loaded. Effectively this changes the PCI probe API, since pci_dev->irq and the device's dma configuration will now only be valid after pci_enable() was called at least once. A more subtle change is that platform specific PCI device setup is moved from device discovery into the driver's probe function, more specifically into the pci_enable_device() call. To fix the inconsistencies, add new function pcibios_add_device. Call pcibios_setup_device from pcibios_setup_bus_devices if device setup is not complete, and from pcibios_add_device if bus setup is complete. With this change, device setup code is moved back into device initialization, and called exactly once for both static and hot plugged devices. [ This also fixes a regression introduced by the above patch which causes dev->irq to be overwritten under some cirumstances after MSIs have been enabled for the device which leads to crashes due to the MSI core "hijacking" dev->irq to store the base MSI number and not the LSI. --BenH ] Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * powerpc/eeh: Add eeh_dev to the cache during bootThadeu Lima de Souza Cascardo2013-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f8f7d63fd96ead101415a1302035137a866f8998 ("powerpc/eeh: Trace eeh device from I/O cache") broke EEH on pseries for devices that were present during boot and have not been hotplugged/DLPARed. eeh_check_failure will get the eeh_dev from the cache, and will get NULL. eeh_addr_cache_build adds the addresses to the cache, but eeh_dev for the giving pci_device is not set yet. Just reordering the call to eeh_addr_cache_insert_dev works fine. The ordering is similar to the one in eeh_add_device_late. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* | ARM: dt: Only print warning, not WARN() on bad cpu map in device treeOlof Johansson2013-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to recent changes and expecations of proper cpu bindings, there are now cases for many of the in-tree devicetrees where a WARN() will hit on boot due to badly formatted /cpus nodes. Downgrade this to a pr_warn() to be less alarmist, since it's not a new problem. Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN without this, the others do not. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | mn10300: Use early_param() to parse "mem=" parameterAkira Takeuchi2013-06-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the problem that "init=" options may not be passed to kernel correctly. parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from redboot_command_line. Then init_setup() parses the "init=" options from static_command_line, which is a copy of redboot_command_line, and keeps the pointer to the init options in execute_command variable. Since the commit 026cee0 upstream (params: <level>_initcall-like kernel parameters), static_command_line becomes overwritten by saved_command_line at do_initcall_level(). Notice that saved_command_line is a command line which includes "mem=" string. As a result, execute_command may point to weird string by the length of "mem=" parameter. I noticed this problem when using the command line like this: mem=128M console=ttyS0,115200 init=/bin/sh Here is the processing flow of command line parameters. start_kernel() setup_arch(&command_line) parse_mem_cmdline(cmdline_p) * strcpy(boot_command_line, redboot_command_line); * Remove "mem=xxx" from redboot_command_line. * *cmdline_p = redboot_command_line; setup_command_line(command_line) <-- command_line is redboot_command_line * strcpy(saved_command_line, boot_command_line) * strcpy(static_command_line, command_line) parse_early_param() strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE); parse_early_options(tmp_cmdline); parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param); parse_args("Booting ..", static_command_line, ...); init_setup() <-- save the pointer in execute_command rest_init() kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND); At this point, execute_command points to "/bin/sh" string. kernel_init() kernel_init_freeable() do_basic_setup() do_initcalls() do_initcall_level() (*) strcpy(static_command_line, saved_command_line); Here, execute_command gets to point to "200" string !! Signed-off-by: David Howells <dhowells@redhat.com>
* | mn10300: Allow to pass array name to get_user()Akira Takeuchi2013-06-28
| | | | | | | | | | | | | | | | | | | | This fixes the following compile error: CC block/scsi_ioctl.o block/scsi_ioctl.c: In function 'sg_scsi_ioctl': block/scsi_ioctl.c:449: error: invalid initializer Signed-off-by: David Howells <dhowells@redhat.com>
* | Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2013-06-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Three small fixlets" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot() hw_breakpoint: Fix cpu check in task_bp_pinned(cpu) kprobes: Fix arch_prepare_kprobe to handle copy insn failures
| * | kprobes: Fix arch_prepare_kprobe to handle copy insn failuresMasami Hiramatsu2013-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix arch_prepare_kprobe() to handle failures in copy instruction correctly. This fix is related to the previous fix: 8101376 which made __copy_instruction return an error result if failed, but caller site was not updated to handle it. Thus, this is the other half of the bugfix. This fix is also related to the following bug-report: https://bugzilla.redhat.com/show_bug.cgi?id=910649 Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Jonathan Lebon <jlebon@redhat.com> Cc: Frank Ch. Eigler <fche@redhat.com> Cc: systemtap@sourceware.org Cc: yrl.pp-manager.tt@hitachi.com Link: http://lkml.kernel.org/r/20130605031216.15285.2001.stgit@mhiramat-M0-7522 Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | | Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds2013-06-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull ARM fixes from Russell King: "Another round of ARM fixes. Largest one is the second half of the PJ4B fix which was pushed in the previous -rc - this one was delayed because its original caused a build regression while trying to fix a regression! As ever, noMMU gets forgotten when fixing problems on MMU, so we have a noMMU fix for a previous fix included in this set. A couple of fixes from Lorenzo for problems with the ARM DT CPU code, and a one liner to remove the buggy 'wait for interrupt' with FA526 cores" * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7773/1: PJ4B: Add support for errata 4742 ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMU ARM: 7763/1: kernel: fix __cpu_logical_map default initialization ARM: 7762/1: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes ARM: 7760/1: cpu_fa526_do_idle: remove WFI
| * | | ARM: 7773/1: PJ4B: Add support for errata 4742Gregory CLEMENT2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes the regression on Armada 370 (the kernal hang during boot) introduced by the commit: "ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead". When coming out of either a Wait for Interrupt (WFI) or a Wait for Event (WFE) IDLE states, a specific timing sensitivity exists between the retiring WFI/WFE instructions and the newly issued subsequent instructions. This sensitivity can result in a CPU hang scenario. The workaround is to insert either a Data Synchronization Barrier (DSB) or Data Memory Barrier (DMB) command immediately after the WFI/WFE instruction. This commit was based on the work of Lior Amsalem, but heavily modified to apply the errata fix dynamically according to the processor type thanks to the suggestions of Russell King and Nicolas Pitre. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Willy Tarreau <w@1wt.eu> Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMUSimon Baatz2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1bc3974 (ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page) moved the implementation of flush_kernel_dcache_page() into mm/flush.c but did not implement it on noMMU ARM. Signed-off-by: Simon Baatz <gmbnomis@gmail.com> Acked-by: Kevin Hilman <khilman@linaro.org> Cc: <stable@vger.kernel.org> # 3.2+: 1bc3974: ARM: 7755/1 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 7763/1: kernel: fix __cpu_logical_map default initializationLorenzo Pieralisi2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __cpu_logical_map array is statically initialized to 0, which is a valid MPIDR value. To prevent issues with the current implementation, this patch defines an MPIDR_INVALID value, and statically initializes the __cpu_logical_map[] array to it. Entries in the arm_dt_init_cpu_maps() tmp_map array used to stash DT reg properties while parsing DT are initialized with the MPIDR_INVALID value as well for consistency. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 7762/1: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodesLorenzo Pieralisi2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The introduction of the cpu-map topology node in the cpus node implies that cpus node might have children that are not cpu nodes. The DT parsing code needs updating otherwise it would check for cpu nodes properties in nodes that are not required to contain them, resulting in warnings that have no bearing on bindings defined in the dts source file. Cc: <stable@vger.kernel.org> [3.8+] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 7760/1: cpu_fa526_do_idle: remove WFIJonas Jensen2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it was already suggested by Russell King and Arnd Bergmann: https://lkml.org/lkml/2013/5/16/133 moxart and gemini seem to be the only platforms using CPU_FA526, and instead of pointing arm_pm_idle to an empty function from platform code, it makes sense to remove WFI code from the processor specific idle function. Applies to arm-soc/for-next (and 3.10-rc1). Changes since v1: 1. remove WFI but make sure cpu_fa526_do_idle do not fall through to cpu_fa526_dcache_clean_area Note: moxart boots and prints to UART without this patch, but input is broken. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | | Merge branch 'for-linus' of ↵Linus Torvalds2013-06-25
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A couple of last-minute fixes: a build regression for !SMP, a recent memory detection patch caused kdump to break, a regression in regard to sscanf vs reboot from FCP, and two fixes in the DMA mapping code for PCI" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/ipl: Fix FCP WWPN and LUN format strings for read s390/mem_detect: fix memory hole handling s390/dma: support debug_dma_mapping_error s390/dma: fix mapping_error detection s390/irq: Only define synchronize_irq() on SMP
| * | | | s390/ipl: Fix FCP WWPN and LUN format strings for readMichael Holzheu2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following git commit changed the behavior of sscanf: commit 53809751ac230a3611b5cdd375f3389f3207d471 Author: Jan Beulich <JBeulich@suse.com> Date: Mon Dec 17 16:01:31 2012 -0800 sscanf: don't ignore field widths for numeric conversions This broke the WWPN and LUN sysfs attributes for s390 reipl and dump on panic. Example: $ echo 0x0123456701234567 > /sys/firmware/reipl/fcp/wwpn $ cat /sys/firmware/reipl/fcp/wwpn 0x0001234567012345 So fix this and use format strings that work also with the new sscanf implementation: $ echo 0x012345670123456789 > /sys/firmware/reipl/fcp/wwpn $ cat /sys/firmware/reipl/fcp/wwpn 0x0123456701234567 Cc: stable@vger.kernel.org # 3.8+ Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/mem_detect: fix memory hole handlingHeiko Carstens2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With git commit 996b4a7d "s390/mem_detect: remove artificial kdump memory types" the memory detection code got simplified. As a side effect the array that describes memory chunks may now contain empty (zeroed) entries. All call sites can handle this except for drivers/s390/char/zcore.c::zcore_memmap_open which has a really odd user space interface. The easiest fix is to change the memory hole handling code, so that no empty entries exist before the last valid entry is reached. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/dma: support debug_dma_mapping_errorSebastian Ott2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch drivers will get blamed (CONFIG_DMA_API_DEBUG=y) for not calling dma_mapping_error (even if they do). Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/dma: fix mapping_error detectionSebastian Ott2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The map_page implementation of s390 returns DMA_ERROR_CODE in an error situation. Correctly test if a mapping was erroneous (DMA_ERROR_CODE is defined as ~0). Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/irq: Only define synchronize_irq() on SMPBen Hutchings2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In uniprocessor configurations, synchronize_irq() is defined in <linux/hardirq.h> as a macro, and this function definition fails to compile. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: stable@vger.kernel.org # 3.9 Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* | | | | Merge branch 'merge' of ↵Linus Torvalds2013-06-25
|\ \ \ \ \ | |_|/ / / |/| | | / | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc bugfix from Ben Herrenschmidt: "This is a fix for a regression causing a freescale "83xx" based platforms to crash on boot due to some PCI breakage" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/pci: Fix boot panic on mpc83xx (regression)
| * | | powerpc/pci: Fix boot panic on mpc83xx (regression)Rojhalat Ibrahim2013-06-24
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit caused a fatal oops when booting on mpc83xx with a non-express PCI bus (regardless of whether a PCI device is present): commit 50d8f87d2b39313dae9d0a2d9b23d377328f2f7b Author: Rojhalat Ibrahim <imr@rtschenk.de> Date: Mon Apr 8 10:15:28 2013 +0200 powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers Up to now the PCIe link status on Freescale PCIe controllers was only checked once at boot time. So hotplug did not work. With this patch the link status is checked on every config read. PCIe devices not present at boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'. Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> This patch fixes the issue by calling setup_indirect_pci for all device types. fsl_indirect_read_config is now only used for booke/86xx PCIe controllers. Reported-by: Michael Guntsche <mike@it-loops.com> Cc: Scott Wood <scottwood@freescale.com> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Scott Wood <scottwood@freescale.com>
* | | Merge tag 'fixes-for-linus' of ↵Linus Torvalds2013-06-22
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "These are two fixes that came in this week, one for a regression we introduced in 3.10 in the GIC interrupt code, and the other one fixes a typo in newly introduced code" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case ARM: dts: Correct the base address of pinctrl_3 on Exynos5250
| * | | ARM: dts: Correct the base address of pinctrl_3 on Exynos5250Padmavathi Venna2013-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corrects the base address of pinctrl_3 on Exynos5250 platform. Signed-off-by: Padmavathi Venna <padma.v@samsung.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Olof Johansson <olof@lixom.net>
* | | | Merge branch 'for-linus' of ↵Linus Torvalds2013-06-22
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro: "Several fixes for bugs caught while looking through f_pos (ab)users" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: aout32 coredump compat fix splice: don't pass the address of ->f_pos to methods mconsole: we'd better initialize pos before passing it to vfs_read()...
| * | | | aout32 coredump compat fixAl Viro2013-06-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dump_seek() does SEEK_CUR, not SEEK_SET; native binfmt_aout handles it correctly (seeks by PAGE_SIZE - sizeof(struct user), getting the current position to PAGE_SIZE), compat one seeks by PAGE_SIZE and ends up at PAGE_SIZE + already written... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | | | mconsole: we'd better initialize pos before passing it to vfs_read()...Al Viro2013-06-19
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | | | Merge branch 'x86/urgent' of ↵Linus Torvalds2013-06-21
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "This series fixes a couple of build failures, and fixes MTRR cleanup and memory setup on very specific memory maps. Finally, it fixes triggering backtraces on all CPUs, which was inadvertently disabled on x86." * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Fix dummy variable buffer allocation x86: Fix trigger_all_cpu_backtrace() implementation x86: Fix section mismatch on load_ucode_ap x86: fix build error and kconfig for ia32_emulation and binfmt range: Do not add new blank slot with add_range_with_merge x86, mtrr: Fix original mtrr range get for mtrr_cleanup
| * \ \ \ \ Merge tag 'efi-urgent' into x86/urgentH. Peter Anvin2013-06-21
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Don't leak random kernel memory to EFI variable NVRAM when attempting to initiate garbage collection. Also, free the kernel memory when we're done with it instead of leaking - Ben Hutchings Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| | * | | | | x86/efi: Fix dummy variable buffer allocationBen Hutchings2013-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Check for allocation failure 2. Clear the buffer contents, as they may actually be written to flash 3. Don't leak the buffer Compile-tested only. [ Tested successfully on my buggy ASUS machine - Matt ] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: stable@vger.kernel.org Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| * | | | | | x86: Fix trigger_all_cpu_backtrace() implementationMichel Lespinasse2013-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following change fixes the x86 implementation of trigger_all_cpu_backtrace(), which was previously (accidentally, as far as I can tell) disabled to always return false as on architectures that do not implement this function. trigger_all_cpu_backtrace(), as defined in include/linux/nmi.h, should call arch_trigger_all_cpu_backtrace() if available, or return false if the underlying arch doesn't implement this function. x86 did provide a suitable arch_trigger_all_cpu_backtrace() implementation, but it wasn't actually being used because it was declared in asm/nmi.h, which linux/nmi.h doesn't include. Also, linux/nmi.h couldn't easily be fixed by including asm/nmi.h, because that file is not available on all architectures. I am proposing to fix this by moving the x86 definition of arch_trigger_all_cpu_backtrace() to asm/irq.h. Tested via: echo l > /proc/sysrq-trigger Before the change, this uses a fallback implementation which shows backtraces on active CPUs (using smp_call_function_interrupt() ) After the change, this shows NMI backtraces on all CPUs Signed-off-by: Michel Lespinasse <walken@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1370518875-1346-1-git-send-email-walken@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
| * | | | | | x86: Fix section mismatch on load_ucode_apPaul Gortmaker2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are in the process of removing all the __cpuinit annotations. While working on making that change, an existing problem was made evident: WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch in reference from the function cpu_init() to the function .init.text:load_ucode_ap() The function cpu_init() references the function __init load_ucode_ap(). This is often because cpu_init lacks a __init annotation or the annotation of load_ucode_ap is wrong. This now appears because in my working tree, cpu_init() is no longer tagged as __cpuinit, and so the audit picks up the mismatch. The 2nd hypothesis from the audit is the correct one, as there was an incorrect __init tag on the prototype in the header (but __cpuinit was used on the function itself.) The audit is telling us that the prototype's __init annotation took effect and the function did land in the .init.text section. Checking with objdump on a mainline tree that still has __cpuinit shows that the __cpuinit on the function takes precedence over the __init on the prototype, but that won't be true once we make __cpuinit a no-op. Even though we are removing __cpuinit, we temporarily align both the function and the prototype on __cpuinit so that the changeset can be applied to stable trees if desired. [ hpa: build fix only, no object code change ] Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable <stable@vger.kernel.org> # 3.9+ Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| * | | | | | x86: fix build error and kconfig for ia32_emulation and binfmtRandy Dunlap2013-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF when COMPAT_BINFMT_ELF is being selected. warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF) fs/built-in.o: In function `elf_core_dump': compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs' compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size' compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs' compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data' [ hpa: This was sent to me for -next but it is a low risk build fix ] Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org Cc: <stable@vger.kernel.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| * | | | | | x86, mtrr: Fix original mtrr range get for mtrr_cleanupYinghai Lu2013-06-18
| | |/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge during add range) broke mtrr cleanup on his setup in 3.9.5. corresponding commit in upstream is fbe06b7bae7c. *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G https://bugzilla.kernel.org/show_bug.cgi?id=59491 So it rejects new var mtrr layout. It turns out we have some problem with initial mtrr range retrieval. The current sequence is: x86_get_mtrr_mem_range ==> bunchs of add_range_with_merge ==> bunchs of subract_range ==> clean_sort_range add_range_with_merge for [0,1M) sort_range() add_range_with_merge could have blank slots, so we can not just sort only, that will have final result have extra blank slot in head. So move that calling add_range_with_merge for [0,1M), with that we could avoid extra clean_sort_range calling. Reported-by: Joshua Covington <joshuacov@googlemail.com> Tested-by: Joshua Covington <joshuacov@googlemail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org Cc: <stable@vger.kernel.org> v3.9 Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
* | | | | | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2013-06-21
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull KVM fixes from Paolo Bonzini: "Three one-line fixes for my first pull request; one for x86 host, one for x86 guest, one for PPC" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: x86: kvmclock: zero initialize pvclock shared memory area kvm/ppc/booke: Delay kvmppc_lazy_ee_enable KVM: x86: remove vcpu's CPL check in host-invoked XCR set
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-26 00:37:39 -0500