1. 24 May, 2012 1 commit
  2. 22 May, 2012 1 commit
  3. 16 May, 2012 11 commits
  4. 15 May, 2012 1 commit
  5. 05 May, 2012 1 commit
  6. 03 May, 2012 1 commit
  7. 26 Apr, 2012 2 commits
  8. 18 Apr, 2012 1 commit
  9. 11 Apr, 2012 3 commits
    • Michael Holzheu's avatar
      [S390] Fix stfle() lowcore protection problem · 37e37c20
      Michael Holzheu authored
      The stfle() function writes into lowcore memory when stfl_fac_list
      is initialized with "S390_lowcore.stfl_fac_list = 0". For older
      compilers this triggers a lowcore exception. With newer compilers
      and "-OXX" compile option the bug does not show up because
      the "S390_lowcore.stfl_fac_list" initialization is removed by the
      compiler. The reason for thatis the incorrect "=m"
      (S390_lowcore.stfl_fac_list) constraint in the stfl inline assembly.
      The following shows the disassembly of the stfle() optimized code
      that is inlined in the lgr_info_get() function:
      000000000011325c <lgr_info_get>:
        11325c:       eb 9f f0 60 00 24       stmg    %r9,%r15,96(%r15)
        113262:       c0 d0 00 29 0e 47       larl    %r13,634ef0 <servi..>
        113268:       a7 f1 3f c0             tml     %r15,16320
        11326c:       b9 04 00 ef             lgr     %r14,%r15
        113270:       a7 84 00 01             je      113272 <lgr_info_g..>
        113274:       a7 fb ff c0             aghi    %r15,-64
        113278:       b9 04 00 c2             lgr     %r12,%r2
        11327c:       a7 29 00 01             lghi    %r2,1
        113280:       e3 e0 f0 98 00 24       stg     %r14,152(%r15)
        113286:       d7 97 c0 00 c0 00       xc      0(152,%r12),0(%r12)
        11328c:       c0 e5 00 28 db 4c       brasl   %r14,62e924 <add_e..>
        113292:       b2 b1 00 00             stfl    0
      To fix the problem we now clear the S390_lowcore.stfl_fac_list at
      startup in "head.S" for all machine types before lowcore protection
      is enabled.
      In addition to that the "=m" constraint is replaced by "+m".
      Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Heiko Carstens's avatar
      [S390] cpum_cf: get rid of compile warnings · af0ee94e
      Heiko Carstens authored
      Fix these:
      arch/s390/kernel/perf_cpum_cf.c:180:3: warning: format '%lx'
         expects argument of type 'long unsigned int',
         but argument 2 has type 'int' [-Wformat]
      arch/s390/kernel/perf_cpum_cf.c: In function 'cpumf_pmu_disable':
      arch/s390/kernel/perf_cpum_cf.c:205:3: warning: format '%lx'
         expects argument of type 'long unsigned int',
         but argument 2 has type 'int' [-Wformat]
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Heiko Carstens's avatar
      [S390] irq: simple coding style change · 7968ca81
      Heiko Carstens authored
      Use braces for if/else/list_for_each_entry bodies if the body consists
      of more than a single line. Otherwise I get confused and check if there
      is something broken whenever I see these code snippets.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  10. 30 Mar, 2012 1 commit
  11. 28 Mar, 2012 1 commit
  12. 23 Mar, 2012 3 commits
    • Jason Baron's avatar
      coredump: remove VM_ALWAYSDUMP flag · 909af768
      Jason Baron authored
      The motivation for this patchset was that I was looking at a way for a
      qemu-kvm process, to exclude the guest memory from its core dump, which
      can be quite large.  There are already a number of filter flags in
      /proc/<pid>/coredump_filter, however, these allow one to specify 'types'
      of kernel memory, not specific address ranges (which is needed in this
      Since there are no more vma flags available, the first patch eliminates
      the need for the 'VM_ALWAYSDUMP' flag.  The flag is used internally by
      the kernel to mark vdso and vsyscall pages.  However, it is simple
      enough to check if a vma covers a vdso or vsyscall page without the need
      for this flag.
      The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
      'VM_NODUMP' flag, which can be set by userspace using new madvise flags:
      'MADV_DONTDUMP', and unset via 'MADV_DODUMP'.  The core dump filters
      continue to work the same as before unless 'MADV_DONTDUMP' is set on the
      The qemu code which implements this features is at:
      In my testing the qemu core dump shrunk from 383MB -> 13MB with this
      I also believe that the 'MADV_DONTDUMP' flag might be useful for
      security sensitive apps, which might want to select which areas are
      This patch:
      The VM_ALWAYSDUMP flag is currently used by the coredump code to
      indicate that a vma is part of a vsyscall or vdso section.  However, we
      can determine if a vma is in one these sections by checking it against
      the gate_vma and checking for a non-NULL return value from
      arch_vma_name().  Thus, freeing a valuable vma bit.
      Signed-off-by: default avatarJason Baron <jbaron@redhat.com>
      Acked-by: default avatarRoland McGrath <roland@hack.frob.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Avi Kivity <avi@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Hendrik Brueckner's avatar
      [S390] perf: add support for s390x CPU counters · 212188a5
      Hendrik Brueckner authored
      Add a perf PMU to access the CPU-measurement counter facility CPUM CF.
      CPUM CF provides multiple counter sets for measuring generic,
      problem-state, and crypto activaties.  Also an extended counter set for
      the IBM System z10 and IBM z196 mainframes is available.
      Counters from the basic and problem-state counter set are mapped to
      generic perf hardware events.  Other counters are accessible through
      raw events.
      For a list of available counter sets and counters, see:
        - The Load-Program-Parameter and the CPU-Measurement Facilities (SA23-2260)
        - The CPU-Measurement Facility Extended Counters Definition for
          z10 and z196 (SA23-2261)
      Reviewed-by: default avatarJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: default avatarHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Jan Glauber's avatar
      [S390] oprofile: Allow multiple users of the measurement alert interrupt · b03d541a
      Jan Glauber authored
      Prepare the measurement facility which is currently only used by oprofile
      for multiple users.  To achieve that the measurement alert interrupt control
      bit needs to be protected.  The measurement alert definitions are moved
      to a header file and an interrupt mask is added so that users can discard
      interrupts if they are for a different measurement subsystem.
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: default avatarJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  13. 13 Mar, 2012 1 commit
  14. 12 Mar, 2012 1 commit
    • Peter Zijlstra's avatar
      sched: Cleanup cpu_active madness · 5fbd036b
      Peter Zijlstra authored
      Stepan found:
      CPU0		CPUn
      		  while (!cpu_active())
        /* we find cpu_online() is true */
        /* wait-forever-more */
      Now the purpose of cpu_active is mostly with bringing down a cpu, where
      we mark it !active to avoid the load-balancer from moving tasks to it
      while we tear down the cpu. This is required because we only update the
      sched_domain tree after we brought the cpu-down. And this is needed so
      that some tasks can still run while we bring it down, we just don't want
      new tasks to appear.
      On cpu-up however the sched_domain tree doesn't yet include the new cpu,
      so its invisible to the load-balancer, regardless of the active state.
      So instead of setting the active state after we boot the new cpu (and
      consequently having to wait for it before enabling interrupts) set the
      cpu active before we set it online and avoid the whole mess.
      Reported-by: default avatarStepan Moskovchenko <stepanm@codeaurora.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1323965362.18942.71.camel@twinsSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
  15. 11 Mar, 2012 10 commits
  16. 01 Mar, 2012 1 commit