1. 14 12月, 2016 1 次提交
  2. 12 12月, 2016 5 次提交
  3. 07 12月, 2016 7 次提交
  4. 02 12月, 2016 2 次提交
    • H
      s390/setup: fix memblock usage · db7ad636
      Heiko Carstens 提交于
      When converting from bootmem to memblock I missed a subtle difference:
      the memblock_alloc() functions return uninitialized memory, while the
      memblock_virt_alloc() functions return zeroed memory.
      
      This led to quite random early boot crashes.
      
      Therefore use the correct version everywhere now.
      Hopefully.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      db7ad636
    • H
      s390/kexec: use node 0 when re-adding crash kernel memory · 9f88eb4d
      Heiko Carstens 提交于
      When re-adding crash kernel memory within setup_resources() the
      function memblock_add() is used. That function will add memory by
      default to node "MAX_NUMNODES" instead of node 0, like the memory
      detection code does. In case of !NUMA this will trigger this warning
      when the kernel generates the vmemmap:
      
      Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
      WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16
      Call Trace:
       [<0000000000d0b2e8>] memblock_virt_alloc_try_nid+0x88/0xc8
       [<000000000083c8ea>] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50
       [<000000000083e7f4>] vmemmap_populate+0x1ac/0x1e0
       [<0000000000840136>] sparse_mem_map_populate+0x46/0x68
       [<0000000000d0c59c>] sparse_init+0x184/0x238
       [<0000000000cf45f6>] paging_init+0xbe/0xf8
       [<0000000000cf1d4a>] setup_arch+0xa02/0xae0
       [<0000000000ced75a>] start_kernel+0x72/0x450
       [<0000000000100020>] _stext+0x20/0x80
      
      If NUMA is selected numa_setup_memory() will fix the node assignments
      before the vmemmap will be populated; so this warning will only appear
      if NUMA is not selected.
      
      To fix this simply use memblock_add_node() and re-add crash kernel
      memory explicitly to node 0.
      Reported-and-tested-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Fixes: 4e042af4 ("s390/kexec: fix crash on resize of reserved memory")
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9f88eb4d
  5. 29 11月, 2016 1 次提交
  6. 25 11月, 2016 1 次提交
  7. 23 11月, 2016 3 次提交
  8. 22 11月, 2016 1 次提交
  9. 17 11月, 2016 1 次提交
  10. 16 11月, 2016 1 次提交
    • C
      locking/core: Introduce cpu_relax_yield() · 79ab11cd
      Christian Borntraeger 提交于
      For spinning loops people do often use barrier() or cpu_relax().
      For most architectures cpu_relax and barrier are the same, but on
      some architectures cpu_relax can add some latency.
      For example on power,sparc64 and arc, cpu_relax can shift the CPU
      towards other hardware threads in an SMT environment.
      On s390 cpu_relax does even more, it uses an hypercall to the
      hypervisor to give up the timeslice.
      In contrast to the SMT yielding this can result in larger latencies.
      In some places this latency is unwanted, so another variant
      "cpu_relax_lowlatency" was introduced. Before this is used in more
      and more places, lets revert the logic and provide a cpu_relax_yield
      that can be called in places where yielding is more important than
      latency. By default this is the same as cpu_relax on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1477386195-32736-2-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79ab11cd
  11. 15 11月, 2016 2 次提交
  12. 12 11月, 2016 1 次提交
  13. 11 11月, 2016 4 次提交
  14. 10 11月, 2016 2 次提交
  15. 01 11月, 2016 1 次提交
  16. 28 10月, 2016 3 次提交
  17. 24 10月, 2016 1 次提交
  18. 17 10月, 2016 3 次提交