1. 16 10月, 2017 1 次提交
  2. 23 8月, 2017 1 次提交
  3. 12 6月, 2017 1 次提交
    • C
      s390/smp: fix false positive kmemleak of mcesa data structure · 9cf8edb7
      Christian Borntraeger 提交于
      I get number of CPUs - 1 kmemleak hits like
      
      unreferenced object 0x37ec6f000 (size 1024):
        comm "swapper/0", pid 1, jiffies 4294937330 (age 889.690s)
        hex dump (first 32 bytes):
          6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
          6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        backtrace:
          [<000000000034a848>] kmem_cache_alloc+0x2b8/0x3d0
          [<00000000001164de>] __cpu_up+0x456/0x488
          [<000000000016f60c>] bringup_cpu+0x4c/0xd0
          [<000000000016d5d2>] cpuhp_invoke_callback+0xe2/0x9e8
          [<000000000016f3c6>] cpuhp_up_callbacks+0x5e/0x110
          [<000000000016f988>] _cpu_up+0xe0/0x158
          [<000000000016faf0>] do_cpu_up+0xf0/0x110
          [<0000000000dae1ee>] smp_init+0x126/0x130
          [<0000000000d9bd04>] kernel_init_freeable+0x174/0x2e0
          [<000000000089fc62>] kernel_init+0x2a/0x148
          [<00000000008adce2>] kernel_thread_starter+0x6/0xc
          [<00000000008adcdc>] kernel_thread_starter+0x0/0xc
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      The pointer of this data structure is stored in the prefix page of that
      CPU together with some extra bits ORed into the the low bits.
      Mark the data structure as non-leak.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9cf8edb7
  4. 22 3月, 2017 2 次提交
    • H
      s390/smp: fix ipl from cpu with non-zero address · 0861b5a7
      Heiko Carstens 提交于
      Commit af51160e ("s390/smp: initialize cpu_present_mask in
      setup_arch") initializes the cpu_present_mask much earlier than
      before. However the cpu detection code relies on the fact that iff
      logical cpu 0 is marked present then also the corresponding physical
      cpu address within the pcpu_devices array slot is valid.
      
      Since commit 44fd2299 ("[PATCH] Register the boot-cpu in the cpu
      maps earlier") this assumption is not true anymore. The patch marks
      logical cpu 0 as present in common code without that architecture code
      had a chance to setup the logical to physical map.
      
      With that change the cpu detection code assumes that the physical cpu
      address of cpu 0 is also 0, which is not necessarily true.
      Subsequently the physical cpu address of the ipl cpu will be mapped to
      a different logical cpu. If that cpu is brought online later the ipl
      cpu will send itself an initial cpu reset sigp signal. This in turn
      completely resets the ipl cpu and the system stops working.
      
      A dump of such a system looks like a "store status" has been
      forgotten. But actually the kernel itself removed all traces which
      would allow to easily tell what went wrong.
      
      To fix this initialize the logical to physical cpu address already in
      smp_setup_processor_id(). In addition remove the initialization of the
      cpu_present_mask and cpu_online_mask for cpu 0, since that has already
      been done. Also add a sanity check, just in case common code will be
      changed again...
      
      The problem can be easily reproduced within a z/VM guest:
      
      > chcpu -d 0
      > vmcp ipl
      
      Fixes: af51160e ("s390/smp: initialize cpu_present_mask in setup_arch")
      Reported-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0861b5a7
    • M
      s390: add a system call for guarded storage · 916cda1a
      Martin Schwidefsky 提交于
      This adds a new system call to enable the use of guarded storage for
      user space processes. The system call takes two arguments, a command
      and pointer to a guarded storage control block:
      
          s390_guarded_storage(int command, struct gs_cb *gs_cb);
      
      The second argument is relevant only for the GS_SET_BC_CB command.
      
      The commands in detail:
      
      0 - GS_ENABLE
          Enable the guarded storage facility for the current task. The
          initial content of the guarded storage control block will be
          all zeros. After the enablement the user space code can use
          load-guarded-storage-controls instruction (LGSC) to load an
          arbitrary control block. While a task is enabled the kernel
          will save and restore the current content of the guarded
          storage registers on context switch.
      1 - GS_DISABLE
          Disables the use of the guarded storage facility for the current
          task. The kernel will cease to save and restore the content of
          the guarded storage registers, the task specific content of
          these registers is lost.
      2 - GS_SET_BC_CB
          Set a broadcast guarded storage control block. This is called
          per thread and stores a specific guarded storage control block
          in the task struct of the current task. This control block will
          be used for the broadcast event GS_BROADCAST.
      3 - GS_CLEAR_BC_CB
          Clears the broadcast guarded storage control block. The guarded-
          storage control block is removed from the task struct that was
          established by GS_SET_BC_CB.
      4 - GS_BROADCAST
          Sends a broadcast to all thread siblings of the current task.
          Every sibling that has established a broadcast guarded storage
          control block will load this control block and will be enabled
          for guarded storage. The broadcast guarded storage control block
          is used up, a second broadcast without a refresh of the stored
          control block with GS_SET_BC_CB will not have any effect.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      916cda1a
  5. 02 3月, 2017 2 次提交
  6. 17 2月, 2017 1 次提交
    • P
      s390: kernel: Audit and remove any unnecessary uses of module.h · 3994a52b
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each change instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3994a52b
  7. 07 12月, 2016 2 次提交
  8. 22 11月, 2016 1 次提交
  9. 11 11月, 2016 2 次提交
  10. 10 11月, 2016 2 次提交
  11. 18 7月, 2016 1 次提交
  12. 28 6月, 2016 1 次提交
  13. 13 6月, 2016 1 次提交
    • M
      s390/mm: simplify the TLB flushing code · 64f31d58
      Martin Schwidefsky 提交于
      ptep_flush_lazy and pmdp_flush_lazy use mm->context.attach_count to
      decide between a lazy TLB flush vs an immediate TLB flush. The field
      contains two 16-bit counters, the number of CPUs that have the mm
      attached and can create TLB entries for it and the number of CPUs in
      the middle of a page table update.
      
      The __tlb_flush_asce, ptep_flush_direct and pmdp_flush_direct functions
      use the attach counter and a mask check with mm_cpumask(mm) to decide
      between a local flush local of the current CPU and a global flush.
      
      For all these functions the decision between lazy vs immediate and
      local vs global TLB flush can be based on CPU masks. There are two
      masks:  the mm->context.cpu_attach_mask with the CPUs that are actively
      using the mm, and the mm_cpumask(mm) with the CPUs that have used the
      mm since the last full flush. The decision between lazy vs immediate
      flush is based on the mm->context.cpu_attach_mask, to decide between
      local vs global flush the mm_cpumask(mm) is used.
      
      With this patch all checks will use the CPU masks, the old counter
      mm->context.attach_count with its two 16-bit values is turned into a
      single counter mm->context.flush_count that keeps track of the number
      of CPUs with incomplete page table updates. The sole user of this
      counter is finish_arch_post_lock_switch() which waits for the end of
      all page table updates.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      64f31d58
  14. 06 5月, 2016 1 次提交
  15. 02 3月, 2016 1 次提交
    • T
      arch/hotplug: Call into idle with a proper state · fc6d73d6
      Thomas Gleixner 提交于
      Let the non boot cpus call into idle with the corresponding hotplug state, so
      the hotplug core can handle the further bringup. That's a first step to
      convert the boot side of the hotplugged cpus to do all the synchronization
      with the other side through the state machine. For now it'll only start the
      hotplug thread and kick the full bringup of the cpu.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Srivatsa S. Bhat" <srivatsa@mit.edu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Turner <pjt@google.com>
      Link: http://lkml.kernel.org/r/20160226182341.614102639@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      fc6d73d6
  16. 19 1月, 2016 1 次提交
  17. 11 1月, 2016 1 次提交
  18. 18 12月, 2015 1 次提交
  19. 27 11月, 2015 5 次提交
  20. 14 10月, 2015 3 次提交
  21. 29 7月, 2015 1 次提交
  22. 29 6月, 2015 1 次提交
  23. 25 6月, 2015 3 次提交
    • M
      s390/kdump: fix nosmt kernel parameter · 1592a8e4
      Michael Holzheu 提交于
      It turned out that SIGP set-multi-threading can only be done once.
      Therefore switching to a different MT level after switching to
      sclp.mtid_prev in the dump case fails.
      
      As a symptom specifying the "nosmt" parameter currently fails for
      the kdump kernel and the kernel starts with multi-threading enabled.
      
      So fix this and issue diag 308 subcode 1 call after collecting the
      CPU states for the dump. Also enhance the diag308_reset() function to
      be usable also with enabled lowcore protection and prefix register != 0.
      After the reset it is possible to switch the MT level again. We have
      to do the reset very early in order not to kill the already initialized
      console. Therefore instead of kmalloc() the corresponding memblock
      functions have to be used. To avoid copying the sclp cpu code into
      sclp_early, we now use the simple sigp loop method for CPU detection.
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1592a8e4
    • M
      s390/smp: cleanup core vs. cpu in the SCLP interface · d08d9430
      Martin Schwidefsky 提交于
      The SCLP interface to query, configure and deconfigure CPUs actually
      operates on cores. For a machine without the multi-threading faciltiy
      a CPU and a core are equivalent but starting with System z13 a core
      can have multiple hardware threads, also referred to as logical CPUs.
      
      To avoid confusion replace the word 'cpu' with 'core' in the SCLP
      interface. Also replace MAX_CPU_ADDRESS with SCLP_MAX_CORES.
      The core-id is an 8-bit field, the maximum thread id is in the range
      0-31. The theoretical limit for the CPU address is therefore 8191.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d08d9430
    • M
      s390/smp: fix sigp cpu detection loop · e7086eb1
      Martin Schwidefsky 提交于
      On a (theoretical) system where the read-cpu-info SCLP command does
      not work but SMT is enabled, the sigp detection loop may not find
      all configured cores. The maximum CPU address needs to be shifted
      with smp_cpu_mt_shift.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e7086eb1
  24. 13 5月, 2015 3 次提交
  25. 13 4月, 2015 1 次提交