1. 05 May, 2014 1 commit
  2. 06 Mar, 2014 1 commit
  3. 05 Mar, 2014 1 commit
  4. 04 Mar, 2014 1 commit
  5. 13 Feb, 2014 1 commit
  6. 16 Jan, 2014 1 commit
  7. 12 Nov, 2013 1 commit
    • Jiri Slaby's avatar
      x86/dumpstack: Fix printk_address for direct addresses · 5f01c988
      Jiri Slaby authored
      Consider a kernel crash in a module, simulated the following way:
      
       static int my_init(void)
       {
               char *map = (void *)0x5;
               *map = 3;
               return 0;
       }
       module_init(my_init);
      
      When we turn off FRAME_POINTERs, the very first instruction in
      that function causes a BUG. The problem is that we print IP in
      the BUG report using %pB (from printk_address). And %pB
      decrements the pointer by one to fix printing addresses of
      functions with tail calls.
      
      This was added in commit 71f9e598 ("x86, dumpstack: Use
      %pB format specifier for stack trace") to fix the call stack
      printouts.
      
      So instead of correct output:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
        IP: [<ffffffffa01ac000>] my_init+0x0/0x10 [pb173]
      
      We get:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
        IP: [<ffffffffa0152000>] 0xffffffffa0151fff
      
      To fix that, we use %pS only for stack addresses printouts (via
      newly added printk_stack_address) and %pB for regs->ip (via
      printk_address). I.e. we revert to the old behaviour for all
      except call stacks. And since from all those reliable is 1, we
      remove that parameter from printk_address.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: joe@perches.com
      Cc: jirislaby@gmail.com
      Link: http://lkml.kernel.org/r/1382706418-8435-1-git-send-email-jslaby@suse.czSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5f01c988
  8. 11 Nov, 2013 1 commit
  9. 08 Nov, 2013 2 commits
  10. 29 Oct, 2013 1 commit
    • Peter Zijlstra's avatar
      perf/x86: Further optimize copy_from_user_nmi() · e00b12e6
      Peter Zijlstra authored
      Now that we can deal with nested NMI due to IRET re-enabling NMIs and
      can deal with faults from NMI by making sure we preserve CR2 over NMIs
      we can in fact simply access user-space memory from NMI context.
      
      So rewrite copy_from_user_nmi() to use __copy_from_user_inatomic() and
      rework the fault path to do the minimal required work before taking
      the in_atomic() fault handler.
      
      In particular avoid perf_sw_event() which would make perf recurse on
      itself (it should be harmless as our recursion protections should be
      able to deal with this -- but why tempt fate).
      
      Also rename notify_page_fault() to kprobes_fault() as that is a much
      better name; there is no notifier in it and its specific to kprobes.
      
      Don measured that his worst case NMI path shrunk from ~300K cycles to
      ~150K cycles.
      
      Cc: Stephane Eranian <eranian@google.com>
      Cc: jmario@redhat.com
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: dave.hansen@linux.intel.com
      Tested-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20131024105206.GM2490@laptop.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e00b12e6
  11. 12 Sep, 2013 2 commits
  12. 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
      deferred.
      
      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=914737Tested-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.comTested-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>
      1160c277
  13. 02 Apr, 2013 1 commit
  14. 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
      state.
      
      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>
      6c1e0256
    • 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
      context.
      
      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>
      56dd9470
  15. 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
      pte_present/pmd_present/pmd_huge.
      
      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>
      954f8571
  16. 07 Feb, 2013 1 commit
  17. 13 Dec, 2012 1 commit
  18. 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>
      91d1aa43
  19. 09 Oct, 2012 1 commit
  20. 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>
      6ba3c97a
  21. 21 Sep, 2012 1 commit
  22. 03 May, 2012 1 commit
  23. 13 Mar, 2012 1 commit
  24. 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 ...
       kernel:Stack:
      
       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.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b0f4c4b3
  25. 05 Dec, 2011 1 commit
  26. 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
      area.
      
      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
      untouched.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Link: http://lkml.kernel.org/r/4E835FE30200007800058464@nat28.tlf.novell.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e05139f2
  27. 16 Aug, 2011 2 commits
  28. 11 Aug, 2011 1 commit
  29. 04 Aug, 2011 1 commit
  30. 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.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a8b0ca17
  31. 26 May, 2011 1 commit
  32. 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>
      37b23e05
  33. 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>
      268bb0ce
  34. 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
      removed.
      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>
      a79e53d8
    • 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>
      f8626854
  35. 26 Oct, 2010 1 commit