- 28 4月, 2012 2 次提交
-
-
由 Will Deacon 提交于
TPIDRURW is a user read/write register forming part of the group of thread registers in more recent versions of the ARM architecture (~v6+). Currently, the kernel does not touch this register, which allows tasks to communicate covertly by reading and writing to the register without context-switching affecting its contents. This patch clears TPIDRURW when TPIDRURO is updated via the set_tls macro, which is called directly from __switch_to. Since the current behaviour makes the register useless to userspace as far as thread pointers are concerned, simply clearing the register (rather than saving and restoring it) will not cause any problems to userspace. Cc: stable@vger.kernel.org Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Boyd 提交于
WARNING: vmlinux.o(.text+0x111b8): Section mismatch in reference from the function arm_memory_present() to the function .init.text:memory_present() The function arm_memory_present() references the function __init memory_present(). This is often because arm_memory_present lacks a __init annotation or the annotation of memory_present is wrong. WARNING: arch/arm/mm/built-in.o(.text+0x1edc): Section mismatch in reference from the function alloc_init_pud() to the function .init.text:alloc_init_section() The function alloc_init_pud() references the function __init alloc_init_section(). This is often because alloc_init_pud lacks a __init annotation or the annotation of alloc_init_section is wrong. Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 23 4月, 2012 11 次提交
-
-
由 Russell King 提交于
Using coherent DMA memory with the OMAP DMA engine results in unpredictable behaviour due to memory ordering issues; as things stand, there is no guarantee that data written to coherent DMA memory will be visible to the DMA hardware. This is because the OMAP dma_write() accessor contains no barriers, necessary on ARMv6 and above. The effect of this can be seen in comments in the OMAP serial driver, which incorrectly talks about cache flushing for the coherent DMA stuff. Rather than adding barriers to the accessors, add it in the DMA support code just before we enable DMA, and just after we disable DMA. This avoids having barriers for every DMA register access. Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Linus Walleij 提交于
The MMCI driver will not work without two IRQs since this is not flagged as a single-irq variant. Looking through the complex IRQ definition for the MMCI on the versatile (including an #if 1 statement forcing MMCI IRQ0 to the VIC) this appears to the the correct IRQ number for both models. Cc: Niklas Hernaeus <niklas.hernaeus@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
The ARM PCS mandates that the length and stride bits of the fpscr are cleared on entry to and return from a public interface. Although signal handlers run asynchronously with respect to the interrupted function, the handler itself expects to run as though it has been called like a normal function. This patch updates the state mirroring the VFP hardware before entry to a signal handler so that it adheres to the PCS. Furthermore, we disable VFP to ensure that we trap on any floating point operation performed by the signal handler and synchronise the hardware appropriately. A check is inserted after the signal handler to avoid redundant flushing if VFP was not used. Reported-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
The user VFP state must be preserved (subject to ucontext modifications) across invocation of a signal handler and this is currently handled by vfp_{preserve,restore}_context in signal.c Since this code requires intimate low-level knowledge of the VFP state, this patch moves it into vfpmodule.c. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
PL310 errata #588369 and #727915 require writes to the debug registers of the cache controller to work around known problems. Writing these registers on L220 may cause deadlock, so ensure that we only perform this operation when we identify a PL310 at probe time. Cc: stable@vger.kernel.org Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
The workaround for PL310 erratum #753970 can lead to deadlock on systems with an L220 cache controller. This patch makes the workaround effective only when the cache controller is identified as a PL310 at probe time. Cc: stable@vger.kernel.org Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory") only affects the ARM 1136 core prior to r1p0. The workaround disassembles the faulting instruction to determine whether it was a read or write access on all v6 cores. An issue has been reported on the ARM 11MPCore whereby loading the faulting instruction may happen in parallel with that page being unmapped, resulting in a deadlock due to the lack of TLB broadcasting in hardware: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html This patch limits the workaround so that it is only used on affected cores, which are known to be UP only. Other v6 cores can rely on the FSR to indicate the access type correctly. Cc: stable@vger.kernel.org Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Benjamin Herrenschmidt 提交于
This gets rid of the unused default senses array, and replaces the incorrect use of IRQ_TYPE_NONE with the new IRQ_TYPE_DEFAULT for the initial set_trigger() call when mapping an interrupt. This in turn makes us read the HW state and update the irq desc accordingly. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
mpic_is_ipi() takes a virq and immediately converts it to a hw_irq. However, one of the two call sites calls it with a ... hw_irq. The other call site also happens to have the hw_irq at hand, so let's change it to just take that as an argument. Also change mpic_is_tm() for consistency. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
If the interrupt and the timeout happen roughly at the same time, we can get into a situation where the timer function is run while the interrupt has already been processed. In this case, the timer function might end up doing an add_timer on an already pending timer, causing a BUG_ON() to trigger. Instead, just skip the whole timeout operation if we see that the timer is pending. The spinlock ensures that the only way that happens is if we already started a new operation and thus the timeout can be ignored. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
The problem was reported by Anton Blanchard. While EEH error happened to the PCI device without the corresponding device driver, kernel crash was seen. Eventually, I successfully reproduced the problem on Firebird-L machine with utility "errinjct". Initially, the device driver for Emulex ethernet MAC has been disabled from .config and force data parity on the Emulex ethernet MAC with help of "errinjct". Eventually, I saw the kernel crash after issueing couple of "lspci -v" command. The root cause behind is that the PCI device, including the reference to the corresponding eeh device, will be removed from the system while EEH does recovery. Afterwards, the PCI device will be probed again and added into the system accordingly. So it's not safe to retrieve the eeh device from the corresponding PCI device after the PCI device has been removed and not added again. The patch fixes the issue and retrieve the eeh device from OF node instead of PCI device after the PCI device has been removed. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Tested-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 22 4月, 2012 1 次提交
-
-
由 Yong Zhang 提交于
Otherwise cpu_active_mask will not set, which lead to other issue. Signed-off-by: NYong Zhang <yong.zhang0@gmail.com> Signed-off-by: NKonrad Eisele <konrad@gaisler.com> Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 4月, 2012 5 次提交
-
-
由 Al Viro 提交于
it's always current->mm Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
pfm_vm_munmap() is simply vm_munmap() and pfm_remove_smpl_mapping() always get current as the first argument. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Linus Torvalds 提交于
This continues the theme started with vm_brk() and vm_munmap(): vm_mmap() does the same thing as do_mmap(), but additionally does the required VM locking. This uninlines (and rewrites it to be clearer) do_mmap(), which sadly duplicates it in mm/mmap.c and mm/nommu.c. But that way we don't have to export our internal do_mmap_pgoff() function. Some day we hopefully don't have to export do_mmap() either, if all modular users can become the simpler vm_mmap() instead. We're actually very close to that already, with the notable exception of the (broken) use in i810, and a couple of stragglers in binfmt_elf. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Like the vm_brk() function, this is the same as "do_munmap()", except it does the VM locking for the caller. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
It does the same thing as "do_brk()", except it handles the VM locking too. It turns out that all external callers want that anyway, so we can make do_brk() static to just mm/mmap.c while at it. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 4月, 2012 8 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
This reverts commit b960d6c4. If we have another thread (very likely) touched the list, we end up hitting a problem "that the next element is wrong because we should be able to cope with that. The problem is that the next->next pointer would be set LIST_POISON1. " (Stefano's comment on the patch). Reverting for now. Suggested-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Mingkai Hu 提交于
Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Mingkai Hu 提交于
Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Mingkai Hu 提交于
Also fix issue of accessing invalid msgr pointer issue. The local msgr pointer in fucntion mpic_msgr_get will be accessed before getting a valid address which will cause kernel crash. Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Mingkai Hu 提交于
In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0: ~/arch/powerpc/include/asm/mpic_msgr.h: In function 'mpic_msgr_set_destination': ~/arch/powerpc/include/asm/mpic_msgr.h:117:2: error: implicit declaration of function 'get_hard_smp_processor_id' make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1 Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Baruch Siach 提交于
Commit ae3a197e (Disintegrate asm/system.h for PowerPC) broke build of assembly files when CONFIG_BOOKE_WDT is enabled as follows: AS arch/powerpc/lib/string.o /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h: Assembler messages: /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:19: Error: Unrecognized opcode: `extern' /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:20: Error: Unrecognized opcode: `extern' Since setup_32.c is the only user of the booke_wdt configuration variables, move the declarations there. Cc: David Howells <dhowells@redhat.com> Signed-off-by: NBaruch Siach <baruch@tkos.co.il> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Timur Tabi 提交于
Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls") replaced platform-specific of_device_id tables with a single function that probes the most of the busses in 85xx device trees. If a specific platform needed additional busses probed, then it could call of_platform_bus_probe() again. Typically, the additional platform-specific busses are children of existing busses that have already been probed. of_platform_bus_probe() does not handle those child busses automatically. Unfortunately, this doesn't actually work. The second (platform-specific) call to of_platform_bus_probe() never finds any of the busses it's asked to find. To remedy this, the platform-specific of_device_id tables are eliminated, and their entries are merged into mpc85xx_common_ids[], so that all busses are probed at once. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Russell King 提交于
This reverts commit 9f855503. Peter Zijlstra says: | Argh, how did that ever make it upstream, please drop. | | Russell, please make that go away upstream. | | Like I said, this is both completely the wrong way to solve, and you're | so not paying attention, see: | | 5fbd036b | 2baab4e9 | e3831edd | | What's even worse: | | git describe --contains 9f855503 --match "v*" | v3.4-rc3~1^2~3 | | that nonsense got merged long after those other commits. Linus Walleij says: | My bad, was because the initial patch was submitted march 9th before | these fixes were merged: | http://marc.info/?l=linux-arm-kernel&m=133159655513844&w=2 | | It was pending for a while in Russell's patch tracker and I | rebased it to -rc2 without paying enough attention to recent | related scheduler fixes ... lesson learned. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 4月, 2012 2 次提交
-
-
由 Paul Gortmaker 提交于
This error appeared in the bcmring_defconfig build: CC arch/arm/mach-bcmring/core.o arch/arm/mach-bcmring/core.c:55: error: macro "AMBA_APB_DEVICE" requires 6 arguments, but only 5 given arch/arm/mach-bcmring/core.c:55: warning: type defaults to 'int' in declaration of 'AMBA_APB_DEVICE' arch/arm/mach-bcmring/core.c:56: error: macro "AMBA_APB_DEVICE" requires 6 arguments, but only 5 given arch/arm/mach-bcmring/core.c:56: warning: type defaults to 'int' in declaration of 'AMBA_APB_DEVICE' arch/arm/mach-bcmring/core.c:134: error: 'uartA_device' undeclared here (not in a function) arch/arm/mach-bcmring/core.c:135: error: 'uartB_device' undeclared here (not in a function) make[2]: *** [arch/arm/mach-bcmring/core.o] Error 1 It appeared as of commit 8ede1ae6 "ARM: amba: bcmring: use common amba device initializers" Note that in include/linux/amba/bus.h we have: #define AMBA_APB_DEVICE(name, busid, id, base, irqs, data) ... There is an a --> A case error in the busid and a missing zero placeholder for the id field. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> [olof: reworded patch subject] Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Avi Kivity 提交于
kvm_set_shared_msr() may not be called in preemptible context, but vmx_set_msr() does so: BUG: using smp_processor_id() in preemptible [00000000] code: qemu-kvm/22713 caller is kvm_set_shared_msr+0x32/0xa0 [kvm] Pid: 22713, comm: qemu-kvm Not tainted 3.4.0-rc3+ #39 Call Trace: [<ffffffff8131fa82>] debug_smp_processor_id+0xe2/0x100 [<ffffffffa0328ae2>] kvm_set_shared_msr+0x32/0xa0 [kvm] [<ffffffffa03a103b>] vmx_set_msr+0x28b/0x2d0 [kvm_intel] ... Making kvm_set_shared_msr() work in preemptible is cleaner, but it's used in the fast path. Making two variants is overkill, so this patch just disables preemption around the call. Reported-by: NDave Jones <davej@redhat.com> Signed-off-by: NAvi Kivity <avi@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
- 18 4月, 2012 8 次提交
-
-
由 Robert Lee 提交于
The imx5_idle() check of the tzic_eanble_wake() return value uses incorrect (inverted) logic causing all attempt to idle to fail. Signed-off-by: NRobert Lee <rob.lee@linaro.org> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Fabio Estevam 提交于
commit 6b783f7c (irq_domain: Remove irq_domain_add_simple() replaced irq_domain_add_simple with irq_domain_add_legacy() Implement this conversion so that imx27-dt can be built again. Reported-by: NChris Ball <cjb@laptop.org> Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Fabio Estevam 提交于
Add support for CONFIG_REGULATOR_FIXED_VOLTAGE. Without this option the mx27_3ds cannot have the external Ethernet functional due to the need of smsc regulators. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Paul Walmsley 提交于
DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src() tries to use __raw_{read,write}l() to read from and write to physical addresses, but those functions take virtual addresses. sparse caught this: arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/timer.c:50:13: got unsigned int arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/timer.c:52:9: got unsigned int Fix by using omap_{read,writel}(), just like the other users of the MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term, removing omap_{read,write}l() is the appropriate thing to do; but this will take some work to do this cleanly. Looks like this was caused by 97933d6c (ARM: OMAP1: dmtimer: conversion to platform devices) that dangerously moved code and changed it in the same patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com> Cc: stable@vger.kernel.org [tony@atomide.com: updated comments to include the breaking commit] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
The current serial UART code, while fidling with ocp idlemode bits, forget about the smart idle wakeup bit even if it is supported by UART IP block. This will lead to missing the module wakeup on OMAP's where the smart idle wakeup is supported. This was the root cause of the console sluggishness issue, I have been observing on OMAP4 devices and also can be potential reason for some other UART wakeup issues. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NKevin Hilman <khilman@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NPaul Walmsley <paul@pwsan.com> Cc: stable@vger.kernel.org Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Govindraj.R 提交于
Commit (7496ba30 ARM: OMAP2+: UART: Add default mux for all uarts) wrongly added muxing of default pads for all uarts. This causes breakage on multiple boards using uart pins for alternate functions. For example, on zoom3 random oopses can be seen with nfsroot as the smsc911x ethernet FIFO timings on GPMC bus are controlled by gpmc_wait2 and gpmc_wait3 pins. This means we can't mux these pads to uart4 functionality as commit 7496ba30 was doing. Not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove the default pad muxing. Note that this is not a complete fix, as we now rely on bootloader set muxing for the uart wake-up events. Further patching is needed to enable wake-up events for uarts that are already muxed to uart mode. Cc: Felipe Balbi <balbi@ti.com> Cc: Kevin Hilman <khilman@ti.com> Acked-by: NRuss Dill <russ.dill@gmail.com> Reported-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> [tony@atomide.com: updated comments to describe oops on zoom3] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Stefano Stabellini 提交于
Use list_for_each_entry_safe and remove the spin_lock acquisition in m2p_find_override. Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Grazvydas Ignotas 提交于
_omap3_sram_configure_core_dpll is called when SDRC is reprogrammed, which is done regardless of CONFIG_PM setting, so we always need it's setup code too. Without this, we hit a BUG() on OMAP3 when kernel is built without CONFIG_PM: Reprogramming SDRC clock to 332000000 Hz ------------[ cut here ]------------ kernel BUG at arch/arm/plat-omap/sram.c:342! Internal error: Oops - BUG: 0 [#1] ARM ... [<c001c694>] (omap3_configure_core_dpll+0x68/0x6c) from [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x1) [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [<c001a478>] (omap2_clk_set_rate+0x14/0x2) [<c001a478>] (omap2_clk_set_rate+0x14/0x20) from [<c001c9dc>] (clk_set_rate+0x54/0x74) [<c001c9dc>] (clk_set_rate+0x54/0x74) from [<c022b9c8>] (omap_sdrc_init+0x70/0x90) [<c022b9c8>] (omap_sdrc_init+0x70/0x90) from [<c022f178>] (omap3pandora_init+0x11c/0x164) [<c022f178>] (omap3pandora_init+0x11c/0x164) from [<c022849c>] (customize_machine+0x20/0x28) [<c022849c>] (customize_machine+0x20/0x28) from [<c0225810>] (do_one_initcall+0xa0/0x16c) [<c0225810>] (do_one_initcall+0xa0/0x16c) from [<c02259e0>] (kernel_init+0x104/0x1ac) [<c02259e0>] (kernel_init+0x104/0x1ac) from [<c0009cec>] (kernel_thread_exit+0x0/0x8) Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 4月, 2012 3 次提交
-
-
由 Greg Ungerer 提交于
The CONFIG_FEC2 define was removed from the kernel many versions ago. But it is still being used to set the multi-function pins when compiling for a ColdFire 527[45] SoC that has 2 ethernet interfaces. Remove the last remaining uses of this define, and so fix the setting of the pins for the 2nd ethernet interface. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Greg Ungerer 提交于
The second ColdFire FEC ethernet device should have an id number of 1, not 0. Otherwise it clashes with the first FEC ethernet device. On booting a kernel on a 5275 based board you will get messages out of the kernel like this: <4>------------[ cut here ]------------ <4>WARNING: at fs/sysfs/dir.c:508 0x0a8b50() <4>sysfs: cannot create duplicate filename 'fec.0' And likely you won't be able to completely boot up after this at all. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Luck, Tony 提交于
Michel Lespinasse cleaned up the futex calling conventions in commit 37a9d912 ("futex: Sanitize cmpxchg_futex_value_locked API"). But the ia64 implementation was subtly broken. Gcc does not know that register "r8" will be updated by the fault handler if the cmpxchg instruction takes an exception. So it feels safe in letting the initialization of r8 slide to after the cmpxchg. Result: we always return 0 whether the user address faulted or not. Fix by moving the initialization of r8 into the __asm__ code so gcc won't move it. Reported-by: <emeric.maschino@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42757 Tested-by: <emeric.maschino@gmail.com> Acked-by: NMichel Lespinasse <walken@google.com> Cc: stable@vger.kernel.org # v2.6.39+ Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-