- 01 2月, 2013 3 次提交
-
-
由 H. Peter Anvin 提交于
We have removed the remap allocator for x86-32, and x86-64 never had it (and doesn't need it). Remove residual reference to it. Reported-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/CAE9FiQVn6_QZi3fNQ-JHYiR-7jeDJ5hT0SyT_%2BzVvfOj=PzF3w@mail.gmail.com
-
由 H. Peter Anvin 提交于
Remove reference to removed function resume_map_numa_kva(). Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
-
由 Dave Hansen 提交于
This code was an optimization for 32-bit NUMA systems. It has probably been the cause of a number of subtle bugs over the years, although the conditions to excite them would have been hard to trigger. Essentially, we remap part of the kernel linear mapping area, and then sometimes part of that area gets freed back in to the bootmem allocator. If those pages get used by kernel data structures (say mem_map[] or a dentry), there's no big deal. But, if anyone ever tried to use the linear mapping for these pages _and_ cared about their physical address, bad things happen. For instance, say you passed __GFP_ZERO to the page allocator and then happened to get handed one of these pages, it zero the remapped page, but it would make a pte to the _old_ page. There are probably a hundred other ways that it could screw with things. We don't need to hang on to performance optimizations for these old boxes any more. All my 32-bit NUMA systems are long dead and buried, and I probably had access to more than most people. This code is causing real things to break today: https://lkml.org/lkml/2013/1/9/376 I looked in to actually fixing this, but it requires surgery to way too much brittle code, as well as stuff like per_cpu_ptr_to_phys(). [ hpa: Cc: this for -stable, since it is a memory corruption issue. However, an alternative is to simply mark NUMA as depends BROKEN rather than EXPERIMENTAL in the X86_32 subclause... ] Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org>
-
- 31 1月, 2013 1 次提交
-
-
由 Borislav Petkov 提交于
... and fix the following warning: arch/x86/mm/numa.c: In function ‘setup_node_data’: arch/x86/mm/numa.c:222:3: warning: passing argument 1 of ‘__phys_addr_nodebug’ makes integer from pointer without a cast Signed-off-by: NBorislav Petkov <bp@suse.de> Acked-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1359245901-8512-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 26 1月, 2013 5 次提交
-
-
由 Dave Hansen 提交于
In short, it is illegal to call __pa() on an address holding a percpu variable. This replaces those __pa() calls with slow_virt_to_phys(). All of the cases in this patch are in boot time (or CPU hotplug time at worst) code, so the slow pagetable walking in slow_virt_to_phys() is not expected to have a performance impact. The times when this actually matters are pretty obscure (certain 32-bit NUMA systems), but it _does_ happen. It is important to keep KVM guests working on these systems because the real hardware is getting harder and harder to find. This bug manifested first by me seeing a plain hang at boot after this message: CPU 0 irqstacks, hard=f3018000 soft=f301a000 or, sometimes, it would actually make it out to the console: [ 0.000000] BUG: unable to handle kernel paging request at ffffffff I eventually traced it down to the KVM async pagefault code. This can be worked around by disabling that code either at compile-time, or on the kernel command-line. The kvm async pagefault code was injecting page faults in to the guest which the guest misinterpreted because its "reason" was not being properly sent from the host. The guest passes a physical address of an per-cpu async page fault structure via an MSR to the host. Since __pa() is broken on percpu data, the physical address it sent was bascially bogus and the host went scribbling on random data. The guest never saw the real reason for the page fault (it was injected by the host), assumed that the kernel had taken a _real_ page fault, and panic()'d. The behavior varied, though, depending on what got corrupted by the bad write. Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20130122212435.4905663F@kernel.stglabs.ibm.comAcked-by: NRik van Riel <riel@redhat.com> Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Dave Hansen 提交于
This is necessary because __pa() does not work on some kinds of memory, like vmalloc() or the alloc_remap() areas on 32-bit NUMA systems. We have some functions to do conversions _like_ this in the vmalloc() code (like vmalloc_to_page()), but they do not work on sizes other than 4k pages. We would potentially need to be able to handle all the page sizes that we use for the kernel linear mapping (4k, 2M, 1G). In practice, on 32-bit NUMA systems, the percpu areas get stuck in the alloc_remap() area. Any __pa() call on them will break and basically return garbage. This patch introduces a new function slow_virt_to_phys(), which walks the kernel page tables on x86 and should do precisely the same logical thing as __pa(), but actually work on a wider range of memory. It should work on the normal linear mapping, vmalloc(), kmap(), etc... Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20130122212433.4D1FCA62@kernel.stglabs.ibm.comAcked-by: NRik van Riel <riel@redhat.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Dave Hansen 提交于
try_preserve_large_page() can be slightly simplified by using the new page_level_*() helpers. This also moves the 'level' over to the new pg_level enum type. Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20130122212432.14F3D993@kernel.stglabs.ibm.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Dave Hansen 提交于
I plan to use lookup_address() to walk the kernel pagetables in a later patch. It returns a "pte" and the level in the pagetables where the "pte" was found. The level is just an enum and needs to be converted to a useful value in order to do address calculations with it. These helpers will be used in at least two places. This also gives the anonymous enum a real name so that no one gets confused about what they should be passing in to these helpers. "PTE_SHIFT" was chosen for naming consistency with the other pagetable levels (PGD/PUD/PMD_SHIFT). Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20130122212431.405D3A8C@kernel.stglabs.ibm.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Dave Hansen 提交于
The KVM code has some repeated bugs in it around use of __pa() on per-cpu data. Those data are not in an area on which using __pa() is valid. However, they are also called early enough in boot that __vmalloc_start_set is not set, and thus the CONFIG_DEBUG_VIRTUAL debugging does not catch them. This adds a check to also verify __pa() calls against max_low_pfn, which we can use earler in boot than is_vmalloc_addr(). However, if we are super-early in boot, max_low_pfn=0 and this will trip on every call, so also make sure that max_low_pfn is set before we try to use it. With this patch applied, CONFIG_DEBUG_VIRTUAL will actually catch the bug I was chasing (and fix later in this series). I'd love to find a generic way so that any __pa() call on percpu areas could do a BUG_ON(), but there don't appear to be any nice and easy ways to check if an address is a percpu one. Anybody have ideas on a way to do this? Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20130122212430.F46F8159@kernel.stglabs.ibm.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 24 1月, 2013 2 次提交
-
-
由 Pawel Moll 提交于
As the kernel is able to cope with multiple clusters, uncomment the A7 cores in the Device Tree for V2P-CA15_A7 tile, making all 5 cores available to the user. Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
由 Lorenzo Pieralisi 提交于
In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a single cpu identifier, affinity levels 1 and 2 must be taken into account as well. This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile secondary cores start up code in order to compare the passed pen_release value with the full-blown affinity mask. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
- 23 1月, 2013 11 次提交
-
-
由 Douglas Gilbert 提交于
Concerning pinctrl_macb0_rmii_mii, values were okay, but not comments. Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Nicolas Ferre 提交于
Reported-by: NJosh Wu <josh.wu@atmel.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Nicolas Ferre 提交于
No need for this cmdline option as we are using DT. Moreover this defconfig is targeted to multiple SoC/boards: this option was nonsense. Reported-by: NJosh Wu <josh.wu@atmel.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Boris BREZILLON 提交于
This patch overrides default macb pinctrl config defined in at91sam9260.dtsi (pinctrl_macb_rmii) with kizbox board config (pinctrl_macb_rmii + pinctrl_macb_rmii_mii_alt). Signed-off-by: NBoris BREZILLON <linux-arm@overkiz.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
Make BGA as the default version as we are supposed to just have to specify when we use the PQFP version. Issue was existing since commit: 3e90772f (ARM: at91: fix at91rm9200 soc subtype handling). Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: stable <stable@vger.kernel.org> [v3.3] Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Joachim Eastwood 提交于
Signed-off-by: NJoachim Eastwood <manabian@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Richard Genoud 提交于
The SCK pins where missing in usarts pinctrl. Signed-off-by: NRichard Genoud <richard.genoud@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Richard Genoud 提交于
The PIN_BANK 3 is for PDxx pins, not PCxx pins. And PIN_BANK 1 is for PBxx, not PIN_BANK 0. Signed-off-by: NRichard Genoud <richard.genoud@gmail.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Sebastian Hesselbarth 提交于
The gpio controller on kirkwood can provide interrupts but is missing the #interrupt-cells property. This patch just adds it to both gpio controllers. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
由 Oleg Nesterov 提交于
putreg() assumes that the tracee is not running and pt_regs_access() can safely play with its stack. However a killed tracee can return from ptrace_stop() to the low-level asm code and do RESTORE_REST, this means that debugger can actually read/modify the kernel stack until the tracee does SAVE_REST again. set_task_blockstep() can race with SIGKILL too and in some sense this race is even worse, the very fact the tracee can be woken up breaks the logic. As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace() call, this ensures that nobody can ever wakeup the tracee while the debugger looks at it. Not only this fixes the mentioned problems, we can do some cleanups/simplifications in arch_ptrace() paths. Probably ptrace_unfreeze_traced() needs more callers, for example it makes sense to make the tracee killable for oom-killer before access_process_vm(). While at it, add the comment into may_ptrace_stop() to explain why ptrace_stop() still can't rely on SIGKILL and signal_pending_state(). Reported-by: NSalman Qazi <sqazi@google.com> Reported-by: NSuleiman Souhlal <suleiman@google.com> Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NOleg Nesterov <oleg@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Will Deacon 提交于
The kernel's internal definition of ELF_NGREG uses struct pt_regs, which means that we disagree with userspace on the size of coredumps since glibc correctly uses the user-visible struct user_pt_regs. This patch fixes our ELF_NGREG definition to use struct user_pt_regs and introduces our own ELF_CORE_COPY_REGS to convert between the user and kernel structure definitions. Cc: <stable@vger.kernel.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 22 1月, 2013 4 次提交
-
-
由 Luciano Coelho 提交于
Add the UART2 muxing data to the board file (this used to be, erroneously, done in the bootloader). Cc: stable <stable@vger.kernel.org> [3.7] Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Pantelis Antoniou 提交于
The iterator correctly handles of_node_put() calls. Remove it before continue'ing the loop. Without this patch you get the following with CONFIG_OF_DYNAMIC set: ERROR: Bad of_node_put() on /ocp/timer@44e31000! [<c001329c>] (unwind_backtrace+0x0/0xe0) from [<c03dd8f0>] (of_node_release+0x2c/0xa0)! [<c03dd8f0>] (of_node_release+0x2c/0xa0) from [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90)! [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90) from [<c06d349c>] (omap_get_timer_dt+0x78/0x90)! [<c06d349c>] (omap_get_timer_dt+0x78/0x90) from [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc)! [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)! [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from [<c06cca58>] (time_init+0x20/0x30)! [<c06cca58>] (time_init+0x20/0x30) from [<c06c9690>] (start_kernel+0x1a8/0x2fc)! Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com> Acked-by: NJon Hunter <jon-hunter@ti.com> [tony@atomide.com: updated description per Jon] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Otherwise we will get: WARNING: vmlinux.o(.text+0x1d4f0): Section mismatch in reference from the function omap_init_ocp2scp() to the function .init.text:omap_device_build() The function omap_init_ocp2scp() references the function __init omap_device_build(). This is often because omap_init_ocp2scp lacks a __init annotation or the annotation of omap_device_build is wrong. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Rob Clark 提交于
Fixes compile break with 3.8-rc4. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 21 1月, 2013 1 次提交
-
-
由 Oleg Nesterov 提交于
The ia64 function "thread_matches()" has no users since commit e868a55c ("[IA64] remove find_thread_for_addr()"). Remove it. This allows us to make ptrace_check_attach() static to kernel/ptrace.c, which is good since we'll need to change the semantics of it and fix up all the callers. Signed-off-by: NOleg Nesterov <oleg@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 1月, 2013 5 次提交
-
-
由 Santosh Shilimkar 提交于
Commit 8fb54284 {ARM: mm: Add strongly ordered descriptor support} added XN flag at section level but missed it at PTE level. Fix it by adding the L_PTE_XN to MT_MEMORY_SO PTE descriptor. Reported-by: NRichard Woodruff <r-woodruff2@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Subhash Jadavani reported this partial backtrace: Now consider this call stack from MMC block driver (this is on the ARMv7 based board): [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114) This is caused by incrementing the struct page pointer, and running off the end of the sparsemem page array. Fix this by incrementing by pfn instead, and convert the pfn to a struct page. Cc: <stable@vger.kernel.org> Suggested-by: NJames Bottomley <JBottomley@Parallels.com> Tested-by: NSubhash Jadavani <subhashj@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Jon Hunter 提交于
During the migration to the common clock framework, calls to the functions omap2xxx_clkt_vps_late_init() were not preserved for OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the following error message to be displayed because the appropriate MPU clock frequency (derived from sys_ck_rate) cannot be found. "Could not set MPU rate to 4294MHz" Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the OMAP2420 and OMAP2430 clock initialisation code. Signed-off-by: NJon Hunter <jon-hunter@ti.com> [paul@pwsan.com: dropped the duplicated call to omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon; updated patch description] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Peter Ujfalusi 提交于
McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> [paul@pwsan.com: copy patch description into hwmod data comments] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Peter Ujfalusi 提交于
To avoid issues with audio caused by non locked ABE DPLL we should make sure it is locked in all OMAP4 revisions. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NJon Hunter <jon-hunter@ti.com> [paul@pwsan.com: cleaned up patch description] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 18 1月, 2013 3 次提交
-
-
由 Peter Chen 提交于
As we use platform_device_id for fsl-usb2-udc driver, it needs to change clk connection-id, or the related devm_clk_get will be failed. Signed-off-by: NPeter Chen <peter.chen@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Peter Chen 提交于
As mach/hardware.h is deleted, we need to use platform_device_id to differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has already used pdata to differentiate runtime Meanwhile we update the platform code accordingly. Signed-off-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Alexander Graf 提交于
Guests can trigger MMIO exits using dcbf. Since we don't emulate cache incoherent MMIO, just do nothing and move on. Reported-by: NBen Collins <ben.c@servergy.com> Signed-off-by: NAlexander Graf <agraf@suse.de> Tested-by: NBen Collins <ben.c@servergy.com> CC: stable@vger.kernel.org
-
- 17 1月, 2013 5 次提交
-
-
由 Dimitris Papastamos 提交于
We are using S3C_EINT(4) instead of S3C_EINT(5). Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Alim Akhtar 提交于
As per the current exynos-dw-mshc bindings, dw-mshc-sdr-timing and dw-mshc-ddr-timing properties are having only two cells, these properties are wrongly set for exynos5250 based cros5250 and smdk5250 platfroms. This patch corrects above timing propreties for above platfroms Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com> Tested-by: NDoug Anderson <dianders@chromium.org> Acked-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Tomasz Figa 提交于
If there is no board selecting CONFIG_S3C_DEV_FB enabled, build will fail on arch/arm/mach-s3c64xx/pm.c, where s3c_device_fb is referenced. This patch adds ifdef guard around the code making it compile only when CONFIG_S3C_DEV_FB is enabled. Signed-off-by: NTomasz Figa <tomasz.figa@gmail.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Uwe Kleine-König 提交于
debug_ll_addr is only used on machines with an MMU so it can be #ifdef'ed out safely. This fixes: arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:104: Error: too many positional arguments The problem was introduced in e5c5f2ad ARM: implement debug_ll_io_init(). Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: NStephen Warren <swarren@nvidia.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Andrew Cooper 提交于
This fixes CVE-2013-0190 / XSA-40 There has been an error on the xen_failsafe_callback path for failed iret, which causes the stack pointer to be wrong when entering the iret_exc error path. This can result in the kernel crashing. In the classic kernel case, the relevant code looked a little like: popl %eax # Error code from hypervisor jz 5f addl $16,%esp jmp iret_exc # Hypervisor said iret fault 5: addl $16,%esp # Hypervisor said segment selector fault Here, there are two identical addls on either option of a branch which appears to have been optimised by hoisting it above the jz, and converting it to an lea, which leaves the flags register unaffected. In the PVOPS case, the code looks like: popl_cfi %eax # Error from the hypervisor lea 16(%esp),%esp # Add $16 before choosing fault path CFI_ADJUST_CFA_OFFSET -16 jz 5f addl $16,%esp # Incorrectly adjust %esp again jmp iret_exc It is possible unprivileged userspace applications to cause this behaviour, for example by loading an LDT code selector, then changing the code selector to be not-present. At this point, there is a race condition where it is possible for the hypervisor to return back to userspace from an interrupt, fault on its own iret, and inject a failsafe_callback into the kernel. This bug has been present since the introduction of Xen PVOPS support in commit 5ead97c8 (xen: Core Xen implementation), in 2.6.23. Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by: NAndrew Cooper <andrew.cooper3@citrix.com> Cc: stable@vger.kernel.org Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-