1. 08 1月, 2013 1 次提交
    • H
      s390/irq: remove split irq fields from /proc/stat · 420f42ec
      Heiko Carstens 提交于
      Now that irq sum accounting for /proc/stat's "intr" line works again we
      have the oddity that the sum field (first field) contains only the sum
      of the second (external irqs) and third field (I/O interrupts).
      The reason for that is that these two fields are already sums of all other
      fields. So if we would sum up everything we would count every interrupt
      twice.
      This is broken since the split interrupt accounting was merged two years
      ago: 052ff461 "[S390] irq: have detailed
      statistics for interrupt types".
      To fix this remove the split interrupt fields from /proc/stat's "intr"
      line again and only have them in /proc/interrupts.
      
      This restores the old behaviour, seems to be the only sane fix and mimics
      a behaviour from other architectures where /proc/interrupts also contains
      more than /proc/stat's "intr" line does.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      420f42ec
  2. 23 11月, 2012 2 次提交
  3. 09 10月, 2012 1 次提交
  4. 26 9月, 2012 3 次提交
  5. 30 7月, 2012 4 次提交
  6. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  7. 16 5月, 2012 5 次提交
  8. 29 3月, 2012 1 次提交
  9. 11 3月, 2012 1 次提交
    • H
      [S390] irq: external interrupt code passing · fde15c3a
      Heiko Carstens 提交于
      The external interrupt handlers have a parameter called ext_int_code.
      Besides the name this paramter does not only contain the ext_int_code
      but in addition also the "cpu address" (POP) which caused the external
      interrupt.
      To make the code a bit more obvious pass a struct instead so the called
      function can easily distinguish between external interrupt code and
      cpu address. The cpu address field however is named "subcode" since
      some external interrupt sources do not pass a cpu address but a
      different parameter (or none at all).
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fde15c3a
  10. 27 2月, 2012 1 次提交
  11. 27 12月, 2011 2 次提交
    • M
      [S390] cleanup trap handling · aa33c8cb
      Martin Schwidefsky 提交于
      Move the program interruption code and the translation exception identifier
      to the pt_regs structure as 'int_code' and 'int_parm_long' and make the
      first level interrupt handler in entry[64].S store the two values. That
      makes it possible to drop 'prot_addr' and 'trap_no' from the thread_struct
      and to reduce the number of arguments to a lot of functions. Finally
      un-inline do_trap. Overall this saves 5812 bytes in the .text section of
      the 64 bit kernel.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      aa33c8cb
    • C
      [S390] disable MACHINE_IS_VM check for pfault · f32269a0
      Carsten Otte 提交于
      This patch disables the check for MACHINE_IS_VM when initializing the
      pfault infrastructure. The code checks for successful completion of
      diag 258 anyway, thus it's safe to try initialization on LPAR anyway.
      This is needed to use pfault on kvm
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f32269a0
  12. 14 11月, 2011 1 次提交
  13. 30 10月, 2011 3 次提交
  14. 24 7月, 2011 1 次提交
    • M
      [S390] kvm guest address space mapping · e5992f2e
      Martin Schwidefsky 提交于
      Add code that allows KVM to control the virtual memory layout that
      is seen by a guest. The guest address space uses a second page table
      that shares the last level pte-tables with the process page table.
      If a page is unmapped from the process page table it is automatically
      unmapped from the guest page table as well.
      
      The guest address space mapping starts out empty, KVM can map any
      individual 1MB segments from the process virtual memory to any 1MB
      aligned location in the guest virtual memory. If a target segment in
      the process virtual memory does not exist or is unmapped while a
      guest mapping exists the desired target address is stored as an
      invalid segment table entry in the guest page table.
      The population of the guest page table is fault driven.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e5992f2e
  15. 01 7月, 2011 1 次提交
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra 提交于
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
  16. 26 5月, 2011 5 次提交
  17. 23 5月, 2011 3 次提交
    • H
      [S390] pfault: cleanup code · 7dd8fe1f
      Heiko Carstens 提交于
      Small code cleanup.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7dd8fe1f
    • H
      [S390] pfault: cpu hotplug vs missing completion interrupts · f2db2e6c
      Heiko Carstens 提交于
      On cpu hot remove a PFAULT CANCEL command is sent to the hypervisor
      which in turn will cancel all outstanding pfault requests that have
      been issued on that cpu (the same happens with a SIGP cpu reset).
      
      The result is that we end up with uninterruptible processes where
      the interrupt that would wake up these processes never arrives.
      
      In order to solve this all processes which wait for a pfault
      completion interrupt get woken up after a cpu hot remove. The worst
      case that could happen is that they fault again and in turn need to
      wait again.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f2db2e6c
    • M
      [S390] Remove data execution protection · 043d0708
      Martin Schwidefsky 提交于
      The noexec support on s390 does not rely on a bit in the page table
      entry but utilizes the secondary space mode to distinguish between
      memory accesses for instructions vs. data. The noexec code relies
      on the assumption that the cpu will always use the secondary space
      page table for data accesses while it is running in the secondary
      space mode. Up to the z9-109 class machines this has been the case.
      Unfortunately this is not true anymore with z10 and later machines.
      The load-relative-long instructions lrl, lgrl and lgfrl access the
      memory operand using the same addressing-space mode that has been
      used to fetch the instruction.
      This breaks the noexec mode for all user space binaries compiled
      with march=z10 or later. The only option is to remove the current
      noexec support.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      043d0708
  18. 29 4月, 2011 1 次提交
  19. 20 4月, 2011 1 次提交
    • H
      [S390] pfault: fix token handling · e35c76cd
      Heiko Carstens 提交于
      f6649a7e "[S390] cleanup lowcore access from external interrupts" changed
      handling of external interrupts. Instead of letting the external interrupt
      handlers accessing the per cpu lowcore the entry code of the kernel reads
      already all fields that are necessary and passes them to the handlers.
      The pfault interrupt handler was incorrectly converted. It tries to
      dereference a value which used to be a pointer to a lowcore field. After
      the conversion however it is not anymore the pointer to the field but its
      content. So instead of a dereference only a cast is needed to get the
      task pointer that caused the pfault.
      
      Fixes a NULL pointer dereference and a subsequent kernel crash:
      
      Unable to handle kernel pointer dereference at virtual kernel address (null)
      Oops: 0004 [#1] SMP
      Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc
                         loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod
                         dasd_eckd_mod dasd_diag_mod dasd_mod
      CPU: 0 Not tainted 2.6.38-2-s390x #1
      Process cron (pid: 1106, task: 000000001f962f78, ksp: 000000001fa0f9d0)
      Krnl PSW : 0404200180000000 000000000002c03e (pfault_interrupt+0xa2/0x138)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
      Krnl GPRS: 0000000000000000 0000000000000001 0000000000000000 0000000000000001
                 000000001f962f78 0000000000518968 0000000090000002 000000001ff03280
                 0000000000000000 000000000064f000 000000001f962f78 0000000000002603
                 0000000006002603 0000000000000000 000000001ff7fe68 000000001ff7fe48
      Krnl Code: 000000000002c036: 5820d010            l       %r2,16(%r13)
                 000000000002c03a: 1832                lr      %r3,%r2
                 000000000002c03c: 1a31                ar      %r3,%r1
                >000000000002c03e: ba23d010            cs      %r2,%r3,16(%r13)
                 000000000002c042: a744fffc            brc     4,2c03a
                 000000000002c046: a7290002            lghi    %r2,2
                 000000000002c04a: e320d0000024        stg     %r2,0(%r13)
                 000000000002c050: 07f0                bcr     15,%r0
      Call Trace:
       ([<000000001f962f78>] 0x1f962f78)
        [<000000000001acda>] do_extint+0xf6/0x138
        [<000000000039b6ca>] ext_no_vtime+0x30/0x34
        [<000000007d706e04>] 0x7d706e04
      Last Breaking-Event-Address:
        [<0000000000000000>] 0x0
      
      For stable maintainers:
      the first kernel which contains this bug is 2.6.37.
      Reported-by: NStephen Powell <zlinuxman@wowway.com>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e35c76cd
  20. 31 3月, 2011 1 次提交
  21. 05 1月, 2011 1 次提交