1. 23 5月, 2014 2 次提交
  2. 08 5月, 2014 20 次提交
  3. 04 5月, 2014 5 次提交
  4. 02 5月, 2014 3 次提交
  5. 30 4月, 2014 1 次提交
    • V
      ARC: !PREEMPT: Ensure Return to kernel mode is IRQ safe · 8aa9e85a
      Vineet Gupta 提交于
      There was a very small race window where resume to kernel mode from a
      Exception Path (or pure kernel mode which is true for most of ARC
      exceptions anyways), was not disabling interrupts in restore_regs,
      clobbering the exception regs
      
      Anton found the culprit call flow (after many sleepless nights)
      
      | 1. we got a Trap from user land
      | 2. started to service it.
      | 3. While doing some stuff on user-land memory (I think it is padzero()),
      |     we got a DataTlbMiss
      | 4. On return from it we are taking "resume_kernel_mode" path
      | 5. NEED_RESHED is not set, so we go to "return from exception" path in
      |     restore regs.
      | 6. there seems to be IRQ happening
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: <stable@vger.kernel.org>   #3.10, 3.12, 3.13, 3.14
      Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
      Cc: Francois Bedard <Francois.Bedard@synopsys.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8aa9e85a
  6. 28 4月, 2014 9 次提交
    • M
      arm: KVM: fix possible misalignment of PGDs and bounce page · 5d4e08c4
      Mark Salter 提交于
      The kvm/mmu code shared by arm and arm64 uses kalloc() to allocate
      a bounce page (if hypervisor init code crosses page boundary) and
      hypervisor PGDs. The problem is that kalloc() does not guarantee
      the proper alignment. In the case of the bounce page, the page sized
      buffer allocated may also cross a page boundary negating the purpose
      and leading to a hang during kvm initialization. Likewise the PGDs
      allocated may not meet the minimum alignment requirements of the
      underlying MMU. This patch uses __get_free_page() to guarantee the
      worst case alignment needs of the bounce page and PGDs on both arm
      and arm64.
      
      Cc: <stable@vger.kernel.org> # 3.10+
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      5d4e08c4
    • T
      genirq: x86: Ensure that dynamic irq allocation does not conflict · 62a08ae2
      Thomas Gleixner 提交于
      On x86 the allocation of irq descriptors may allocate interrupts which
      are in the range of the GSI interrupts. That's wrong as those
      interrupts are hardwired and we don't have the irq domain translation
      like PPC. So one of these interrupts can be hooked up later to one of
      the devices which are hard wired to it and the io_apic init code for
      that particular interrupt line happily reuses that descriptor with a
      completely different configuration so hell breaks lose.
      
      Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
      except for a few usage sites which have not yet blown up in our face
      for whatever reason. But for drivers which need an irq range, like the
      GPIO drivers, we have no limit in place and we don't want to expose
      such a detail to a driver.
      
      To cure this introduce a function which an architecture can implement
      to impose a lower bound on the dynamic interrupt allocations.
      
      Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
      the end of the hardwired interrupt space, so all dynamic allocations
      happen above.
      
      That not only allows the GPIO driver to work sanely, it also protects
      the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
      htirq code. They need to be cleaned up as well, but that's a separate
      issue.
      Reported-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Krogerus Heikki <heikki.krogerus@intel.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      62a08ae2
    • B
      KVM: x86: Check for host supported fields in shadow vmcs · fe2b201b
      Bandan Das 提交于
      We track shadow vmcs fields through two static lists,
      one for read only and another for r/w fields. However, with
      addition of new vmcs fields, not all fields may be supported on
      all hosts. If so, copy_vmcs12_to_shadow() trying to vmwrite on
      unsupported hosts will result in a vmwrite error. For example, commit
      36be0b9d introduced GUEST_BNDCFGS, which is not supported
      by all processors. Filter out host unsupported fields before
      letting guests use shadow vmcs
      Signed-off-by: NBandan Das <bsd@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fe2b201b
    • O
      x86/vsmp: Fix irq routing · 39025ba3
      Oren Twaig 提交于
      Correct IRQ routing in case a vSMP box is detected
      but the  Interrupt Routing Comply (IRC) value is set to
      "comply", which leads to incorrect IRQ routing.
      
      Before the patch:
      
      When a vSMP box was detected and IRC was set to "comply",
      users (and the kernel) couldn't effectively set the
      destination of the IRQs. This is because the hook inside
      vsmp_64.c always setup all CPUs as the IRQ destination using
      cpumask_setall() as the return value for IRQ allocation mask.
      Later, this "overrided" mask caused the kernel to set the IRQ
      destination to the lowest online CPU in the mask (CPU0 usually).
      
      After the patch:
      
      When the IRC is set to "comply", users (and the kernel) can control
      the destination of the IRQs as we will not be changing the
      default "apic->vector_allocation_domain".
      Signed-off-by: NOren Twaig <oren@scalemp.com>
      Acked-by: NShai Fultheim <shai@scalemp.com>
      Link: http://lkml.kernel.org/r/1398669697-2123-1-git-send-email-oren@scalemp.com
      [ Minor readability edits. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      39025ba3
    • A
      powerpc/4xx: Fix section mismatch in ppc4xx_pci.c · e4565362
      Alistair Popple 提交于
      This patch fixes this section mismatch:
      
      WARNING: vmlinux.o(.text+0x1efc4): Section mismatch in reference from
      the function apm821xx_pciex_init_port_hw() to the function
      .init.text:ppc4xx_pciex_wait_on_sdr.isra.9()
      
      The function apm821xx_pciex_init_port_hw() references the function
      __init ppc4xx_pciex_wait_on_sdr.isra.9().  This is often because
      apm821xx_pciex_init_port_hw lacks a __init annotation or the
      annotation of ppc4xx_pciex_wait_on_sdr.isra.9 is wrong.
      
      apm821xx_pciex_init_port_hw is only referenced by a struct in
      __initdata, so it should be safe to add __init to
      apm821xx_pciex_init_port_hw.
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e4565362
    • P
      ppc/kvm: Clear the runlatch bit of a vcpu before napping · 582b910e
      Preeti U Murthy 提交于
      When the guest cedes the vcpu or the vcpu has no guest to
      run it naps. Clear the runlatch bit of the vcpu before
      napping to indicate an idle cpu.
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      582b910e
    • P
      ppc/kvm: Set the runlatch bit of a CPU just before starting guest · fd17dc7b
      Preeti U Murthy 提交于
      The secondary threads in the core are kept offline before launching guests
      in kvm on powerpc: "371fefd6:KVM: PPC: Allow book3s_hv guests to use
      SMT processor modes."
      
      Hence their runlatch bits are cleared. When the secondary threads are called
      in to start a guest, their runlatch bits need to be set to indicate that they
      are busy. The primary thread has its runlatch bit set though, but there is no
      harm in setting this bit once again. Hence set the runlatch bit for all
      threads before they start guest.
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fd17dc7b
    • P
      ppc/powernv: Set the runlatch bits correctly for offline cpus · f2038911
      Preeti U Murthy 提交于
      Up until now we have been setting the runlatch bits for a busy CPU and
      clearing it when a CPU enters idle state. The runlatch bit has thus
      been consistent with the utilization of a CPU as long as the CPU is online.
      
      However when a CPU is hotplugged out the runlatch bit is not cleared. It
      needs to be cleared to indicate an unused CPU. Hence this patch has the
      runlatch bit cleared for an offline CPU just before entering an idle state
      and sets it immediately after it exits the idle state.
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f2038911
    • L
      powerpc/pseries: Protect remove_memory() with device hotplug lock · 42dbfc86
      Li Zhong 提交于
      While testing memory hot-remove, I found following dead lock:
      
      Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
      It holds the memory_hotplug_mutex, and blocks when trying to remove file
      "online" under dir memory499, in kernfs_drain(), at
              wait_event(root->deactivate_waitq,
                         atomic_read(&kn->active) == KN_DEACTIVATED_BIAS);
      
      Process #1120 is trying to online memory499 by
         echo 1 > memory499/online
      
      In .kernfs_fop_write, it uses kernfs_get_active() to increase
      &kn->active, thus blocking process #1141. While itself is blocked later
      when trying to acquire memory_hotplug_mutex, which is held by process
      
      The backtrace of both processes are shown below:
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c000000000263ca4>] .online_pages+0x74/0x7b0
      [<c00000000055b40c>] .memory_subsys_online+0x9c/0x150
      [<c00000000053cbe8>] .device_online+0xb8/0x120
      [<c00000000053cd04>] .online_store+0xb4/0xc0
      [<c000000000538ce4>] .dev_attr_store+0x64/0xa0
      [<c00000000030f4ec>] .sysfs_kf_write+0x7c/0xb0
      [<c00000000030e574>] .kernfs_fop_write+0x154/0x1e0
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c00000000030be14>] .__kernfs_remove+0x204/0x300
      [<c00000000030d428>] .kernfs_remove_by_name_ns+0x68/0xf0
      [<c00000000030fb38>] .sysfs_remove_file_ns+0x38/0x60
      [<c000000000539354>] .device_remove_attrs+0x54/0xc0
      [<c000000000539fd8>] .device_del+0x158/0x250
      [<c00000000053a104>] .device_unregister+0x34/0xa0
      [<c00000000055bc14>] .unregister_memory_section+0x164/0x170
      [<c00000000024ee18>] .__remove_pages+0x108/0x4c0
      [<c00000000004b590>] .arch_remove_memory+0x60/0xc0
      [<c00000000026446c>] .remove_memory+0x8c/0xe0
      [<c00000000007f9f4>] .pseries_remove_memblock+0xd4/0x160
      [<c00000000007fcfc>] .pseries_memory_notifier+0x27c/0x290
      [<c0000000008ae6cc>] .notifier_call_chain+0x8c/0x100
      [<c0000000000d858c>] .__blocking_notifier_call_chain+0x6c/0xe0
      [<c00000000071ddec>] .of_property_notify+0x7c/0xc0
      [<c00000000071ed3c>] .of_update_property+0x3c/0x1b0
      [<c0000000000756cc>] .ofdt_write+0x3dc/0x740
      [<c0000000002f60fc>] .proc_reg_write+0xac/0x110
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      This patch uses lock_device_hotplug() to protect remove_memory() called
      in pseries_remove_memblock(), which is also stated before function
      remove_memory():
      
       * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
       * and online/offline operations before this call, as required by
       * try_offline_node().
       */
      void __ref remove_memory(int nid, u64 start, u64 size)
      
      With this lock held, the other process(#1120 above) trying to online the
      memory block will retry the system call when calling
      lock_device_hotplug_sysfs(), and finally find No such device error.
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      42dbfc86