1. 21 Nov, 2014 1 commit
  2. 12 Sep, 2013 2 commits
  3. 29 Jun, 2013 1 commit
  4. 09 Oct, 2012 1 commit
  5. 16 May, 2012 1 commit
  6. 05 May, 2012 1 commit
  7. 10 Apr, 2012 1 commit
  8. 28 Mar, 2012 1 commit
  9. 24 Mar, 2012 1 commit
  10. 08 Dec, 2011 2 commits
  11. 06 Dec, 2011 1 commit
  12. 17 Oct, 2011 1 commit
  13. 19 Jul, 2011 1 commit
  14. 02 Jul, 2011 1 commit
  15. 01 Jul, 2011 1 commit
    • Peter Zijlstra's avatar
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra authored
      
      
      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: default avatarPeter 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.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a8b0ca17
  16. 21 Feb, 2011 1 commit
  17. 15 Feb, 2011 1 commit
  18. 22 Dec, 2010 1 commit
    • Russell King's avatar
      ARM: pgtable: switch order of Linux vs hardware page tables · d30e45ee
      Russell King authored
      
      
      This switches the ordering of the Linux vs hardware page tables in
      each page, thereby eliminating some of the arithmetic in the page
      table walks.  As we now place the Linux page table at the beginning
      of the page, we can deal with the offset in the pgt by simply masking
      it away, along with the other control bits.
      
      This also makes the arithmetic all be positive, rather than a mixture.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d30e45ee
  19. 08 Sep, 2010 1 commit
  20. 27 Jul, 2010 5 commits
  21. 08 Jun, 2010 1 commit
  22. 15 May, 2010 1 commit
  23. 12 Feb, 2010 1 commit
  24. 05 Oct, 2009 1 commit
    • Imre Deak's avatar
      ARM: 5742/1: ARM: add debug check for invalid kernel page faults · 1d212712
      Imre Deak authored
      
      
      According to the following in arch/arm/mm/fault.c page faults from
      kernel mode are invalid if mmap_sem is already held and there is
      no exception handler defined for the faulting instruction:
      
      /*
       * As per x86, we may deadlock here.  However, since the kernel only
       * validly references user space from well defined areas of the code,
       * we can bug out early if this is from code which shouldn't.
       */
      if (!down_read_trylock(&mm->mmap_sem)) {
      	if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))
      		goto no_context;
      
      Since mmap_sem can be held at arbitrary times by another thread this
      also means that any page faults from kernel mode are invalid if no
      exception handler is defined for them, regardless whether mmap_sem is
      held at the time of fault.
      
      To easier detect code that can trigger the above error, add a check
      also for the case where mmap_sem is acquired. As this has an overhead
      make it a VM debug check.
      Signed-off-by: default avatarImre Deak <imre.deak@nokia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      1d212712
  25. 02 Oct, 2009 2 commits
    • Kirill A. Shutemov's avatar
      ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7 · d25ef8b8
      Kirill A. Shutemov authored
      
      
      Currently, on ARMv6 and ARMv7, if an application tries to execute
      code (or garbage) on non-executable page it hangs. It caused by
      incorrect prefetch abort handling. Now every prefetch abort
      processes as a translation fault.
      
      To fix this we have to analyze instruction fault status register
      to figure out reason why we've got the abort and process it
      accordingly.
      
      To make IFSR different from DFSR we set bit 31 which is reserved in
      both IFSR and DFSR.
      
      This patch also tries to protect from future hangs on unexpected
      exceptions. An application will be killed if unexpected exception
      type was received.
      Signed-off-by: default avatarKirill A. Shutemov <kirill@shutemov.name>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d25ef8b8
    • Kirill A. Shutemov's avatar
      ARM: 5727/1: Pass IFSR register to do_PrefetchAbort() · 4fb28474
      Kirill A. Shutemov authored
      
      
      Instruction fault status register, IFSR, was introduced on ARMv6 to
      provide status information about the last insturction fault. It
      needed for proper prefetch abort handling.
      
      Now we have three prefetch abort model:
      
        * legacy - for CPUs before ARMv6. They doesn't provide neither
          IFSR nor IFAR. We simulate IFSR with section translation fault
          status for them to generalize code;
        * ARMv6 - provides IFSR, but not IFAR;
        * ARMv7 - provides both IFSR and IFAR.
      Signed-off-by: default avatarKirill A. Shutemov <kirill@shutemov.name>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      4fb28474
  26. 20 Sep, 2009 5 commits
  27. 17 Aug, 2009 1 commit
  28. 24 Jul, 2009 2 commits