1. 08 Nov, 2013 1 commit
  2. 12 Sep, 2013 2 commits
  3. 10 Apr, 2013 1 commit
    • Samu Kallio's avatar
      x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates · 1160c277
      Samu Kallio authored
      In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
      when lazy MMU updates are enabled, because set_pgd effects are being
      One instance of this problem is during process mm cleanup with memory
      cgroups enabled. The chain of events is as follows:
      - zap_pte_range enables lazy MMU updates
      - zap_pte_range eventually calls mem_cgroup_charge_statistics,
        which accesses the vmalloc'd mem_cgroup per-cpu stat area
      - vmalloc_fault is triggered which tries to sync the corresponding
        PGD entry with set_pgd, but the update is deferred
      - vmalloc_fault oopses due to a mismatch in the PUD entries
      The OOPs usually looks as so:
      ------------[ cut here ]------------
      kernel BUG at arch/x86/mm/fault.c:396!
      invalid opcode: 0000 [#1] SMP
      .. snip ..
      CPU 1
      Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
      RIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
      .. snip ..
      Call Trace:
       [<ffffffff81627759>] do_page_fault+0x399/0x4b0
       [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
       [<ffffffff81624065>] page_fault+0x25/0x30
       [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
       [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
       [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
       [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
       [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
       [<ffffffff81153e61>] unmap_single_vma+0x531/0x870
       [<ffffffff81154962>] unmap_vmas+0x52/0xa0
       [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
       [<ffffffff8115c8f8>] exit_mmap+0x98/0x170
       [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
       [<ffffffff81059ce3>] mmput+0x83/0xf0
       [<ffffffff810624c4>] exit_mm+0x104/0x130
       [<ffffffff8106264a>] do_exit+0x15a/0x8c0
       [<ffffffff810630ff>] do_group_exit+0x3f/0xa0
       [<ffffffff81063177>] sys_exit_group+0x17/0x20
       [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b
      Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
      changes visible to the consistency checks.
      Cc: <stable@vger.kernel.org>
      RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
      Tested-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Reported-and-Tested-by: default avatarKrishna Raman <kraman@redhat.com>
      Signed-off-by: default avatarSamu Kallio <samu.kallio@aberdeencloud.com>
      Link: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com
      Tested-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  4. 02 Apr, 2013 1 commit
  5. 07 Mar, 2013 2 commits
    • Frederic Weisbecker's avatar
      context_tracking: Restore correct previous context state on exception exit · 6c1e0256
      Frederic Weisbecker authored
      On exception exit, we restore the previous context tracking state based on
      the regs of the interrupted frame. Iff that frame is in user mode as
      stated by user_mode() helper, we restore the context tracking user mode.
      However there is a tiny chunck of low level arch code after we pass through
      user_enter() and until the CPU eventually resumes userspace.
      If an exception happens in this tiny area, exception_enter() correctly
      exits the context tracking user mode but exception_exit() won't restore
      it because of the value returned by user_mode(regs).
      As a result we may return to userspace with the wrong context tracking
      To fix this, change exception_enter() to return the context tracking state
      prior to its call and pass this saved state to exception_exit(). This restores
      the real context tracking state of the interrupted frame.
      (May be this patch was suggested to me, I don't recall exactly. If so,
      sorry for the missing credit).
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Mats Liljegren <mats.liljegren@enea.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    • Frederic Weisbecker's avatar
      context_tracking: Move exception handling to generic code · 56dd9470
      Frederic Weisbecker authored
      Exceptions handling on context tracking should share common
      treatment: on entry we exit user mode if the exception triggered
      in that context. Then on exception exit we return to that previous
      Generalize this to avoid duplication across archs.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Mats Liljegren <mats.liljegren@enea.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  6. 24 Feb, 2013 1 commit
    • Andrea Arcangeli's avatar
      Revert "x86, mm: Make spurious_fault check explicitly check explicitly check the PRESENT bit" · 954f8571
      Andrea Arcangeli authored
      I got a report for a minor regression introduced by commit
      027ef6c8 ("mm: thp: fix pmd_present for split_huge_page and
      PROT_NONE with THP").
      So the problem is, pageattr creates kernel pagetables (pte and
      pmds) that breaks pte_present/pmd_present and the patch above
      exposed this invariant breakage for pmd_present.
      The same problem already existed for the pte and pte_present and
      it was fixed by commit 660a293e
       ("x86, mm: Make
      spurious_fault check explicitly check the PRESENT bit") (if it
      wasn't for that commit, it wouldn't even be a regression).  That
      fix avoids the pagefault to use pte_present.  I could follow
      through by stopping using pmd_present/pmd_huge too.
      However I think it's more robust to fix pageattr and to clear
      the PSE/GLOBAL bitflags too in addition to the present bitflag.
      So the kernel page fault can keep using the regular
      The confusion arises because _PAGE_GLOBAL and _PAGE_PROTNONE are
      sharing the same bit, and in the pmd case we pretend _PAGE_PSE
      to be set only in present pmds (to facilitate split_huge_page
      final tlb flush).
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: "H. Peter Anvin" <hpa@linux.intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  7. 07 Feb, 2013 1 commit
  8. 13 Dec, 2012 1 commit
  9. 30 Nov, 2012 1 commit
    • Frederic Weisbecker's avatar
      context_tracking: New context tracking susbsystem · 91d1aa43
      Frederic Weisbecker authored
      Create a new subsystem that probes on kernel boundaries
      to keep track of the transitions between level contexts
      with two basic initial contexts: user or kernel.
      This is an abstraction of some RCU code that use such tracking
      to implement its userspace extended quiescent state.
      We need to pull this up from RCU into this new level of indirection
      because this tracking is also going to be used to implement an "on
      demand" generic virtual cputime accounting. A necessary step to
      shutdown the tick while still accounting the cputime.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      [ paulmck: fix whitespace error and email address. ]
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
  10. 09 Oct, 2012 1 commit
  11. 26 Sep, 2012 1 commit
    • Frederic Weisbecker's avatar
      x86: Exception hooks for userspace RCU extended QS · 6ba3c97a
      Frederic Weisbecker authored
      Add necessary hooks to x86 exception for userspace
      RCU extended quiescent state support.
      This includes traps, page fault, debug exceptions, etc...
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Alessio Igor Bogani <abogani@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Max Krasnyansky <maxk@qualcomm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Sven-Thorsten Dietrich <thebigcorporation@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
  12. 21 Sep, 2012 1 commit
  13. 03 May, 2012 1 commit
  14. 13 Mar, 2012 1 commit
  15. 26 Jan, 2012 1 commit
    • Prarit Bhargava's avatar
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava authored
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      For example, after a softlockup we get:
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      For example, in the case of a softlockup we now see the much
      more informative:
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      instead of the above confusing messages.
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.com
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  16. 05 Dec, 2011 1 commit
  17. 28 Sep, 2011 1 commit
    • Jan Beulich's avatar
      x86-64: Don't apply destructive erratum workaround on unaffected CPUs · e05139f2
      Jan Beulich authored
      Erratum 93 applies to AMD K8 CPUs only, and its workaround
      (forcing the upper 32 bits of %rip to all get set under certain
      conditions) is actually getting in the way of analyzing page
      faults occurring during EFI physical mode runtime calls (in
      particular the page table walk shown is completely unrelated to
      the actual fault). This is because typically EFI runtime code
      lives in the space between 2G and 4G, which - modulo the above
      manipulation - is likely to overlap with the kernel or modules
      While even for the other errata workarounds their taking effect
      could be limited to just the affected CPUs, none of them appears
      to be destructive, and they're generally getting called only
      outside of performance critical paths, so they're being left
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Link: http://lkml.kernel.org/r/4E835FE30200007800058464@nat28.tlf.novell.com
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  18. 16 Aug, 2011 2 commits
  19. 11 Aug, 2011 1 commit
  20. 04 Aug, 2011 1 commit
  21. 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>
  22. 26 May, 2011 1 commit
  23. 25 May, 2011 1 commit
    • KOSAKI Motohiro's avatar
      x86,mm: make pagefault killable · 37b23e05
      KOSAKI Motohiro authored
      When an oom killing occurs, almost all processes are getting stuck at the
      following two points.
      	1) __alloc_pages_nodemask
      	2) __lock_page_or_retry
      1) is not very problematic because TIF_MEMDIE leads to an allocation
      failure and getting out from page allocator.
      2) is more problematic.  In an OOM situation, zones typically don't have
      page cache at all and memory starvation might lead to greatly reduced IO
      performance.  When a fork bomb occurs, TIF_MEMDIE tasks don't die quickly,
      meaning that a fork bomb may create new process quickly rather than the
      oom-killer killing it.  Then, the system may become livelocked.
      This patch makes the pagefault interruptible by SIGKILL.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  24. 20 May, 2011 1 commit
    • Linus Torvalds's avatar
      sanitize <linux/prefetch.h> usage · 268bb0ce
      Linus Torvalds authored
      Commit e66eed65
       ("list: remove prefetching from regular list
      iterators") removed the include of prefetch.h from list.h, which
      uncovered several cases that had apparently relied on that rather
      obscure header file dependency.
      So this fixes things up a bit, using
         grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
         grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')
      to guide us in finding files that either need <linux/prefetch.h>
      inclusion, or have it despite not needing it.
      There are more of them around (mostly network drivers), but this gets
      many core ones.
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 10 Mar, 2011 2 commits
    • Andrea Arcangeli's avatar
      x86/mm: Fix pgd_lock deadlock · a79e53d8
      Andrea Arcangeli authored
      It's forbidden to take the page_table_lock with the irq disabled
      or if there's contention the IPIs (for tlb flushes) sent with
      the page_table_lock held will never run leading to a deadlock.
      Nobody takes the pgd_lock from irq context so the _irqsave can be
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Tested-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@kernel.org>
      LKML-Reference: <201102162345.p1GNjMjm021738@imap1.linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Andrey Vagin's avatar
      x86/mm: Handle mm_fault_error() in kernel space · f8626854
      Andrey Vagin authored
      mm_fault_error() should not execute oom-killer, if page fault
      occurs in kernel space.  E.g. in copy_from_user()/copy_to_user().
      This would happen if we find ourselves in OOM on a
      copy_to_user(), or a copy_from_user() which faults.
      Without this patch, the kernels hangs up in copy_from_user(),
      because OOM killer sends SIG_KILL to current process, but it
      can't handle a signal while in syscall, then the kernel returns
      to copy_from_user(), reexcute current command and provokes
      page_fault again.
      With this patch the kernel return -EFAULT from copy_from_user().
      The code, which checks that page fault occurred in kernel space,
      has been copied from do_sigbus().
      This situation is handled by the same way on powerpc, xtensa,
      tile, ...
      Signed-off-by: default avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@kernel.org>
      LKML-Reference: <201103092322.p29NMNPH001682@imap1.linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  26. 26 Oct, 2010 2 commits
  27. 20 Oct, 2010 1 commit
  28. 19 Oct, 2010 1 commit
  29. 14 Oct, 2010 1 commit
    • Frederic Weisbecker's avatar
      x86: Barf when vmalloc and kmemcheck faults happen in NMI · ebc8827f
      Frederic Weisbecker authored
      In x86, faults exit by executing the iret instruction, which then
      reenables NMIs if we faulted in NMI context. Then if a fault
      happens in NMI, another NMI can nest after the fault exits.
      But we don't yet support nested NMIs because we have only one NMI
      stack. To prevent from that, check that vmalloc and kmemcheck
      faults don't happen in this context. Most of the other kernel faults
      in NMIs can be more easily spotted by finding explicit
      copy_from,to_user() calls on review.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
  30. 08 Oct, 2010 1 commit
    • Andi Kleen's avatar
      x86: HWPOISON: Report correct address granuality for huge hwpoison faults · f672b49b
      Andi Kleen authored
      An earlier patch fixed the hwpoison fault handling to encode the
      huge page size in the fault code of the page fault handler.
      This is needed to report this information in SIGBUS to user space.
      This is a straight forward patch to pass this information
      through to the signal handling in the x86 specific fault.c
      Cc: x86@kernel.org
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: fengguang.wu@intel.com
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
  31. 26 Aug, 2010 2 commits
  32. 13 Aug, 2010 1 commit
    • Linus Torvalds's avatar
      x86: don't send SIGBUS for kernel page faults · 96054569
      Linus Torvalds authored
      It's wrong for several reasons, but the most direct one is that the
      fault may be for the stack accesses to set up a previous SIGBUS.  When
      we have a kernel exception, the kernel exception handler does all the
      fixups, not some user-level signal handler.
      Even apart from the nested SIGBUS issue, it's also wrong to give out
      kernel fault addresses in the signal handler info block, or to send a
      SIGBUS when a system call already returns EFAULT.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  33. 23 Nov, 2009 1 commit
  34. 21 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar authored
      Bye-bye Performance Counters, welcome Performance Events!
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      User-space tooling and ABI compatibility is not affected - this patch
      should be function-invariant. (Also, defconfigs were not touched to
      keep the size down.)
      This patch has been generated via the following script:
        FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
        sed -i \
          -e 's/PERF_EVENT_/PERF_RECORD_/g' \
          -e 's/PERF_COUNTER/PERF_EVENT/g' \
          -e 's/perf_counter/perf_event/g' \
          -e 's/nb_counters/nb_events/g' \
          -e 's/swcounter/swevent/g' \
          -e 's/tpcounter_event/tp_event/g' \
        for N in $(find . -name perf_counter.[ch]); do
          M=$(echo $N | sed 's/perf_counter/perf_event/g')
          mv $N $M
        FILES=$(find . -name perf_event.*)
        sed -i \
          -e 's/COUNTER_MASK/REG_MASK/g' \
          -e 's/COUNTER/EVENT/g' \
          -e 's/\<event\>/event_id/g' \
          -e 's/counter/event/g' \
          -e 's/Counter/Event/g' \
      ... to keep it as correct as possible. This script can also be
      used by anyone who has pending perfcounters patches - it converts
      a Linux kernel tree over to the new naming. We tried to time this
      change to the point in time where the amount of pending patches
      is the smallest: the end of the merge window.
      Namespace clashes were fixed up in a preparatory patch - and some
      stylistic fallout will be fixed up in a subsequent patch.
      ( NOTE: 'counters' are still the proper terminology when we deal
        with hardware registers - and these sed scripts are a bit
        over-eager in renaming them. I've undone some of that, but
        in case there's something left where 'counter' would be
        better than 'event' we can undo that on an individual basis
        instead of touching an otherwise nicely automated patch. )
      Suggested-by: default avatarStephane Eranian <eranian@google.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Reviewed-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>