1. 22 1月, 2015 2 次提交
  2. 15 1月, 2015 9 次提交
    • J
      iommu/irq_remapping: Kill function irq_remapping_supported() and related code · c392f56c
      Jiang Liu 提交于
      Simplify irq_remapping code by killing irq_remapping_supported() and
      related interfaces.
      
      Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
      so assume an signed-off from Joerg.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-14-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c392f56c
    • J
      x86/apic: Only disable CPU x2apic mode when necessary · 5fcee53c
      Jiang Liu 提交于
      When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
      will be disabled if:
      1) Maximum CPU APIC ID is bigger than 255
      2) hypervisior doesn't support x2apic mode.
      
      But we should only check whether hypervisor supports X2APIC mode when
      hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, otherwise X2APIC will
      always be disabled when CONFIG_HYPERVISOR_GUEST is disabled and IR
      doesn't work in X2APIC mode.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-12-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5fcee53c
    • J
      x86/apic: Handle XAPIC remap mode proper. · ef1b2b8a
      Jiang Liu 提交于
      If remapping is in XAPIC mode, the setup code just skips X2APIC
      initialization without checking max CPU APIC ID in system, which may
      cause problem if system has a CPU with APIC ID bigger than 255.
      
      Handle IR in XAPIC mode the same way as if remapping is disabled.
      
      [ tglx: Split out from previous patch ]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-8-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      ef1b2b8a
    • J
      x86/apic: Refine enable_IR_x2apic() and related functions · 07806c50
      Jiang Liu 提交于
      Refine enable_IR_x2apic() and related functions for better readability.
      
      [ tglx: Removed the XAPIC mode change and split it out into a seperate
        	patch. Added comments. ]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-8-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      07806c50
    • J
      x86/apic: Correctly detect X2APIC status in function enable_IR() · 89356cf2
      Jiang Liu 提交于
      X2APIC will be disabled if user specifies "nox2apic" on kernel command
      line, even when x2apic_preenabled is true. So correctly detect X2APIC
      status by using x2apic_enabled() instead of x2apic_preenabled.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-7-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      89356cf2
    • J
      x86/apic: Kill useless variable x2apic_enabled in function enable_IR_x2apic() · 7f530a27
      Jiang Liu 提交于
      Local variable x2apic_enabled has been assigned to but never referred,
      so kill it.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-6-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7f530a27
    • J
      x86/apic: Panic if kernel doesn't support x2apic but BIOS has enabled x2apic · 2599094f
      Jiang Liu 提交于
      When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
      may panic or hang without useful messages. On the other hand, it's
      hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
      So panic with a clear message in such a case.
      
      Now system panics as below when X2APIC is disabled and interrupt remapping
      is enabled:
      [    0.316118] LAPIC pending interrupts after 512 EOI
      [    0.322126] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
      [    0.368655] Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC
      [    0.378300] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0+ #340
      [    0.385300] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0051.L05.1406240953 06/24/2014
      [    0.396997]  ffff88046dc03000 ffff88046c307dd8 ffffffff8179dada 00000000000043f2
      [    0.405629]  ffffffff81a92158 ffff88046c307e58 ffffffff8179b757 0000000000000002
      [    0.414261]  0000000000000008 ffff88046c307e68 ffff88046c307e08 ffffffff813ad82b
      [    0.422890] Call Trace:
      [    0.425711]  [<ffffffff8179dada>] dump_stack+0x45/0x57
      [    0.431533]  [<ffffffff8179b757>] panic+0xc1/0x1f5
      [    0.436978]  [<ffffffff813ad82b>] ? delay_tsc+0x3b/0x70
      [    0.442910]  [<ffffffff8166fa2c>] panic_if_irq_remap+0x1c/0x20
      [    0.449524]  [<ffffffff81d73645>] setup_IO_APIC+0x405/0x82e
      [    0.464979]  [<ffffffff81d6fcc2>] native_smp_prepare_cpus+0x2d9/0x31c
      [    0.472274]  [<ffffffff81d5d0ac>] kernel_init_freeable+0xd6/0x223
      [    0.479170]  [<ffffffff81792ad0>] ? rest_init+0x80/0x80
      [    0.485099]  [<ffffffff81792ade>] kernel_init+0xe/0xf0
      [    0.490932]  [<ffffffff817a537c>] ret_from_fork+0x7c/0xb0
      [    0.497054]  [<ffffffff81792ad0>] ? rest_init+0x80/0x80
      [    0.502983] ---[ end Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC
      
      System hangs as below when X2APIC and interrupt remapping are both disabled:
      [    1.102782] pci 0000:00:02.0: System wakeup disabled by ACPI
      [    1.109351] pci 0000:00:03.0: System wakeup disabled by ACPI
      [    1.115915] pci 0000:00:03.2: System wakeup disabled by ACPI
      [    1.122479] pci 0000:00:03.3: System wakeup disabled by ACPI
      [    1.132274] pci 0000:00:1c.0: Enabling MPC IRBNCE
      [    1.137620] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled
      [    1.145239] pci 0000:00:1c.0: System wakeup disabled by ACPI
      [    1.151790] pci 0000:00:1c.7: Enabling MPC IRBNCE
      [    1.157128] pci 0000:00:1c.7: Intel PCH root port ACS workaround enabled
      [    1.164748] pci 0000:00:1c.7: System wakeup disabled by ACPI
      [    1.171447] pci 0000:00:1e.0: System wakeup disabled by ACPI
      [    1.178612] acpiphp: Slot [8] registered
      [    1.183095] pci 0000:00:02.0: PCI bridge to [bus 01]
      [    1.188867] acpiphp: Slot [2] registered
      
      With this patch applied, the system panics in both cases with a proper
      panic message.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Link: http://lkml.kernel.org/r/1420615903-28253-5-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2599094f
    • T
      x86/apic: Clear stale x2apic mode · f7ccadac
      Thomas Gleixner 提交于
      If x2apic got disabled on the kernel command line, then the following
      issue can happen:
      
      enable_IR_x2apic()
         ....
         x2apic_mode = 1;
         enable_x2apic();
      
           if (x2apic_disabled) {
      	__disable_x2apic();
      	return;
           }
      
      That leaves X2APIC disabled in hardware, but x2apic_mode stays 1. So
      all other code which checks x2apic_mode gets the wrong information.
      
      Set x2apic_mode to 0 after disabling it in hardware.
      
      This is just a hotfix. The proper solution is to rework this code so
      it has seperate functions for the initial setup on the boot processor
      and the secondary cpus, but that's beyond the scope of this fix.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      f7ccadac
    • T
      iommu, x86: Restructure setup of the irq remapping feature · a1dafe85
      Thomas Gleixner 提交于
      enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
      installs the intel dmar remapping ops and then calls the amd iommu irq
      remapping prepare callback to figure out whether we are running on an
      AMD machine with irq remapping hardware.
      
      Right after that it calls irq_remapping_prepare() which pointlessly
      checks:
      	if (!remap_ops || !remap_ops->prepare)
                     return -ENODEV;
      and then calls
      
          remap_ops->prepare()
      
      which is silly in the AMD case as it got called from
      setup_irq_remapping_ops() already a few microseconds ago.
      
      Simplify this and just collapse everything into
      irq_remapping_prepare().
      
      The irq_remapping_prepare() remains still silly as it assigns blindly
      the intel ops, but that's not scope of this patch.
      
      The scope here is to move the preperatory work, i.e. memory
      allocations out of the atomic section which is required to enable irq
      remapping.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Acked-and-tested-by: NJoerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Oren Twaig <oren@scalemp.com>
      Cc: x86@kernel.org
      Link: http://lkml.kernel.org/r/20141205084147.232633738@linutronix.de
      Link: http://lkml.kernel.org/r/1420615903-28253-2-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      a1dafe85
  3. 16 12月, 2014 22 次提交
  4. 13 12月, 2014 1 次提交
  5. 26 11月, 2014 1 次提交
    • S
      x86/nmi: Fix use of unallocated cpumask_var_t · db086554
      Sasha Levin 提交于
      Commit "x86/nmi: Perform a safe NMI stack trace on all CPUs" has introduced
      a cpumask_var_t variable:
      
      	+static cpumask_var_t printtrace_mask;
      
      But never allocated it before using it, which caused a NULL ptr deref when
      trying to print the stack trace:
      
      [ 1110.296154] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1110.296169] IP: __memcpy (arch/x86/lib/memcpy_64.S:151)
      [ 1110.296178] PGD 4c34b3067 PUD 4c351b067 PMD 0
      [ 1110.296186] Oops: 0002 [#1] PREEMPT SMP KASAN
      [ 1110.296234] Dumping ftrace buffer:
      [ 1110.296330]    (ftrace buffer empty)
      [ 1110.296339] Modules linked in:
      [ 1110.296345] CPU: 1 PID: 10538 Comm: trinity-c99 Not tainted 3.18.0-rc5-next-20141124-sasha-00058-ge2a8c09-dirty #1499
      [ 1110.296348] task: ffff880152650000 ti: ffff8804c3560000 task.ti: ffff8804c3560000
      [ 1110.296357] RIP: __memcpy (arch/x86/lib/memcpy_64.S:151)
      [ 1110.296360] RSP: 0000:ffff8804c3563870  EFLAGS: 00010246
      [ 1110.296363] RAX: 0000000000000000 RBX: ffffe8fff3c4a809 RCX: 0000000000000000
      [ 1110.296366] RDX: 0000000000000008 RSI: ffffffff9e254040 RDI: 0000000000000000
      [ 1110.296369] RBP: ffff8804c3563908 R08: 0000000000ffffff R09: 0000000000ffffff
      [ 1110.296371] R10: 0000000000000000 R11: 0000000000000006 R12: 0000000000000000
      [ 1110.296375] R13: 0000000000000000 R14: ffffffff9e254040 R15: ffffe8fff3c4a809
      [ 1110.296379] FS:  00007f9e43b0b700(0000) GS:ffff880107e00000(0000) knlGS:0000000000000000
      [ 1110.296382] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1110.296385] CR2: 0000000000000000 CR3: 00000004e4334000 CR4: 00000000000006a0
      [ 1110.296400] Stack:
      [ 1110.296406]  ffffffff81b1e46c 0000000000000000 ffff880107e03fb8 000000000000000b
      [ 1110.296413]  ffff880107dfffc0 ffff880107e03fc0 0000000000000008 ffffffff93f2e9c8
      [ 1110.296419]  0000000000000000 ffffda0020fc07f7 0000000000000008 ffff8804c3563901
      [ 1110.296420] Call Trace:
      [ 1110.296429] ? memcpy (mm/kasan/kasan.c:275)
      [ 1110.296437] ? arch_trigger_all_cpu_backtrace (include/linux/bitmap.h:215 include/linux/cpumask.h:506 arch/x86/kernel/apic/hw_nmi.c:76)
      [ 1110.296444] arch_trigger_all_cpu_backtrace (include/linux/bitmap.h:215 include/linux/cpumask.h:506 arch/x86/kernel/apic/hw_nmi.c:76)
      [ 1110.296451] ? dump_stack (./arch/x86/include/asm/preempt.h:95 lib/dump_stack.c:55)
      [ 1110.296458] do_raw_spin_lock (./arch/x86/include/asm/spinlock.h:86 kernel/locking/spinlock_debug.c:130 kernel/locking/spinlock_debug.c:137)
      [ 1110.296468] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
      [ 1110.296474] ? __page_check_address (include/linux/spinlock.h:309 mm/rmap.c:630)
      [ 1110.296481] __page_check_address (include/linux/spinlock.h:309 mm/rmap.c:630)
      [ 1110.296487] ? preempt_count_sub (kernel/sched/core.c:2615)
      [ 1110.296493] try_to_unmap_one (include/linux/rmap.h:202 mm/rmap.c:1146)
      [ 1110.296504] ? anon_vma_interval_tree_iter_next (mm/interval_tree.c:72 mm/interval_tree.c:103)
      [ 1110.296514] rmap_walk (mm/rmap.c:1653 mm/rmap.c:1725)
      [ 1110.296521] ? page_get_anon_vma (include/linux/rcupdate.h:423 include/linux/rcupdate.h:935 mm/rmap.c:435)
      [ 1110.296530] try_to_unmap (mm/rmap.c:1545)
      [ 1110.296536] ? page_get_anon_vma (mm/rmap.c:437)
      [ 1110.296545] ? try_to_unmap_nonlinear (mm/rmap.c:1138)
      [ 1110.296551] ? SyS_msync (mm/rmap.c:1501)
      [ 1110.296558] ? page_remove_rmap (mm/rmap.c:1409)
      [ 1110.296565] ? page_get_anon_vma (mm/rmap.c:448)
      [ 1110.296571] ? anon_vma_ctor (mm/rmap.c:1496)
      [ 1110.296579] migrate_pages (mm/migrate.c:913 mm/migrate.c:956 mm/migrate.c:1136)
      [ 1110.296586] ? _raw_spin_unlock_irq (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:169 kernel/locking/spinlock.c:199)
      [ 1110.296593] ? buffer_migrate_lock_buffers (mm/migrate.c:1584)
      [ 1110.296601] ? handle_mm_fault (mm/memory.c:3163 mm/memory.c:3223 mm/memory.c:3336 mm/memory.c:3365)
      [ 1110.296607] migrate_misplaced_page (mm/migrate.c:1738)
      [ 1110.296614] handle_mm_fault (mm/memory.c:3170 mm/memory.c:3223 mm/memory.c:3336 mm/memory.c:3365)
      [ 1110.296623] __do_page_fault (arch/x86/mm/fault.c:1246)
      [ 1110.296630] ? vtime_account_user (kernel/sched/cputime.c:701)
      [ 1110.296638] ? get_parent_ip (kernel/sched/core.c:2559)
      [ 1110.296646] ? context_tracking_user_exit (kernel/context_tracking.c:144)
      [ 1110.296656] trace_do_page_fault (arch/x86/mm/fault.c:1329 include/linux/jump_label.h:114 include/linux/context_tracking_state.h:27 include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1330)
      [ 1110.296664] do_async_page_fault (arch/x86/kernel/kvm.c:280)
      [ 1110.296670] async_page_fault (arch/x86/kernel/entry_64.S:1285)
      [ 1110.296755] Code: 08 4c 8b 54 16 f0 4c 8b 5c 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 90 83 fa 08 72 1b 4c 8b 06 4c 8b 4c 16 f8 <4c> 89 07 4c 89 4c 17 f8 c3 66 2e 0f 1f 84 00 00 00 00 00 83 fa
      All code
      ========
         0:   08 4c 8b 54             or     %cl,0x54(%rbx,%rcx,4)
         4:   16                      (bad)
         5:   f0 4c 8b 5c 16 f8       lock mov -0x8(%rsi,%rdx,1),%r11
         b:   4c 89 07                mov    %r8,(%rdi)
         e:   4c 89 4f 08             mov    %r9,0x8(%rdi)
        12:   4c 89 54 17 f0          mov    %r10,-0x10(%rdi,%rdx,1)
        17:   4c 89 5c 17 f8          mov    %r11,-0x8(%rdi,%rdx,1)
        1c:   c3                      retq
        1d:   90                      nop
        1e:   83 fa 08                cmp    $0x8,%edx
        21:   72 1b                   jb     0x3e
        23:   4c 8b 06                mov    (%rsi),%r8
        26:   4c 8b 4c 16 f8          mov    -0x8(%rsi,%rdx,1),%r9
        2b:*  4c 89 07                mov    %r8,(%rdi)               <-- trapping instruction
        2e:   4c 89 4c 17 f8          mov    %r9,-0x8(%rdi,%rdx,1)
        33:   c3                      retq
        34:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
        3b:   00 00 00
        3e:   83 fa 00                cmp    $0x0,%edx
      
      Code starting with the faulting instruction
      ===========================================
         0:   4c 89 07                mov    %r8,(%rdi)
         3:   4c 89 4c 17 f8          mov    %r9,-0x8(%rdi,%rdx,1)
         8:   c3                      retq
         9:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
        10:   00 00 00
        13:   83 fa 00                cmp    $0x0,%edx
      [ 1110.296760] RIP __memcpy (arch/x86/lib/memcpy_64.S:151)
      [ 1110.296763]  RSP <ffff8804c3563870>
      [ 1110.296765] CR2: 0000000000000000
      
      Link: http://lkml.kernel.org/r/1416931560-10603-1-git-send-email-sasha.levin@oracle.comSigned-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      db086554
  6. 23 11月, 2014 2 次提交
    • T
      PCI/MSI: Rename mask/unmask_msi_irq treewide · 280510f1
      Thomas Gleixner 提交于
      The PCI/MSI irq chip callbacks mask/unmask_msi_irq have been renamed
      to pci_msi_mask/unmask_irq to mark them PCI specific. Rename all usage
      sites. The conversion helper functions are kept around to avoid
      conflicts in next and will be removed after merging into mainline.
      
      Coccinelle assisted conversion. No functional change.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: x86@kernel.org
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Mohit Kumar <mohit.kumar@st.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      280510f1
    • J
      PCI/MSI: Rename write_msi_msg() to pci_write_msi_msg() · 83a18912
      Jiang Liu 提交于
      Rename write_msi_msg() to pci_write_msi_msg() to mark it as PCI
      specific.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      83a18912
  7. 20 11月, 2014 1 次提交
  8. 05 11月, 2014 2 次提交