1. 31 1月, 2015 1 次提交
  2. 30 1月, 2015 1 次提交
    • L
      vm: add VM_FAULT_SIGSEGV handling support · 33692f27
      Linus Torvalds 提交于
      The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
      "you should SIGSEGV" error, because the SIGSEGV case was generally
      handled by the caller - usually the architecture fault handler.
      
      That results in lots of duplication - all the architecture fault
      handlers end up doing very similar "look up vma, check permissions, do
      retries etc" - but it generally works.  However, there are cases where
      the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
      
      In particular, when accessing the stack guard page, libsigsegv expects a
      SIGSEGV.  And it usually got one, because the stack growth is handled by
      that duplicated architecture fault handler.
      
      However, when the generic VM layer started propagating the error return
      from the stack expansion in commit fee7e49d ("mm: propagate error
      from stack expansion even for guard page"), that now exposed the
      existing VM_FAULT_SIGBUS result to user space.  And user space really
      expected SIGSEGV, not SIGBUS.
      
      To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
      duplicate architecture fault handlers about it.  They all already have
      the code to handle SIGSEGV, so it's about just tying that new return
      value to the existing code, but it's all a bit annoying.
      
      This is the mindless minimal patch to do this.  A more extensive patch
      would be to try to gather up the mostly shared fault handling logic into
      one generic helper routine, and long-term we really should do that
      cleanup.
      
      Just from this patch, you can generally see that most architectures just
      copied (directly or indirectly) the old x86 way of doing things, but in
      the meantime that original x86 model has been improved to hold the VM
      semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
      "newer" things, so it would be a good idea to bring all those
      improvements to the generic case and teach other architectures about
      them too.
      Reported-and-tested-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      33692f27
  3. 08 8月, 2014 1 次提交
  4. 06 11月, 2013 1 次提交
  5. 03 11月, 2013 1 次提交
    • V
      ARC: Incorrect mm reference used in vmalloc fault handler · 9c41f4ee
      Vineet Gupta 提交于
      A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current
      task's "active_mm".  ARC vmalloc fault handler however was using mm.
      
      A vmalloc fault for non user task context (actually pre-userland, from
      init thread's open for /dev/console) caused the handler to deref NULL mm
      (for mm->pgd)
      
      The reasons it worked so far is amazing:
      
      1. By default (!SMP), vmalloc fault handler uses a cached value of PGD.
         In SMP that MMU register is repurposed hence need for mm pointer deref.
      
      2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in
         pre-userland code path - it was introduced with commit 20bafb3d
         "n_tty: Move buffers into n_tty_data"
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: stable@vger.kernel.org    #3.10 and 3.11
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c41f4ee
  6. 13 9月, 2013 2 次提交
    • J
      arch: mm: pass userspace fault flag to generic fault handler · 759496ba
      Johannes Weiner 提交于
      Unlike global OOM handling, memory cgroup code will invoke the OOM killer
      in any OOM situation because it has no way of telling faults occuring in
      kernel context - which could be handled more gracefully - from
      user-triggered faults.
      
      Pass a flag that identifies faults originating in user space from the
      architecture-specific fault handlers to generic code so that memcg OOM
      handling can be improved.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: azurIt <azurit@pobox.sk>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      759496ba
    • J
      arch: mm: remove obsolete init OOM protection · 94bce453
      Johannes Weiner 提交于
      The memcg code can trap tasks in the context of the failing allocation
      until an OOM situation is resolved.  They can hold all kinds of locks
      (fs, mm) at this point, which makes it prone to deadlocking.
      
      This series converts memcg OOM handling into a two step process that is
      started in the charge context, but any waiting is done after the fault
      stack is fully unwound.
      
      Patches 1-4 prepare architecture handlers to support the new memcg
      requirements, but in doing so they also remove old cruft and unify
      out-of-memory behavior across architectures.
      
      Patch 5 disables the memcg OOM handling for syscalls, readahead, kernel
      faults, because they can gracefully unwind the stack with -ENOMEM.  OOM
      handling is restricted to user triggered faults that have no other
      option.
      
      Patch 6 reworks memcg's hierarchical OOM locking to make it a little
      more obvious wth is going on in there: reduce locked regions, rename
      locking functions, reorder and document.
      
      Patch 7 implements the two-part OOM handling such that tasks are never
      trapped with the full charge stack in an OOM situation.
      
      This patch:
      
      Back before smart OOM killing, when faulting tasks were killed directly on
      allocation failures, the arch-specific fault handlers needed special
      protection for the init process.
      
      Now that all fault handlers call into the generic OOM killer (see commit
      609838cf: "mm: invoke oom-killer from remaining unconverted page
      fault handlers"), which already provides init protection, the
      arch-specific leftovers can be removed.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: azurIt <azurit@pobox.sk>
      Acked-by: Vineet Gupta <vgupta@synopsys.com>	[arch/arc bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      94bce453
  7. 10 7月, 2013 1 次提交
    • J
      mm: invoke oom-killer from remaining unconverted page fault handlers · 609838cf
      Johannes Weiner 提交于
      A few remaining architectures directly kill the page faulting task in an
      out of memory situation.  This is usually not a good idea since that
      task might not even use a significant amount of memory and so may not be
      the optimal victim to resolve the situation.
      
      Since 2.6.29's 1c0fe6e3 ("mm: invoke oom-killer from page fault") there
      is a hook that architecture page fault handlers are supposed to call to
      invoke the OOM killer and let it pick the right task to kill.  Convert
      the remaining architectures over to this hook.
      
      To have the previous behavior of simply taking out the faulting task the
      vm.oom_kill_allocating_task sysctl can be set to 1.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: Vineet Gupta <vgupta@synopsys.com>   [arch/arc bits]
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      609838cf
  8. 26 6月, 2013 1 次提交
  9. 22 6月, 2013 2 次提交
    • V
      ARC: [mm] Remove @write argument to do_page_fault() · 3e1ae441
      Vineet Gupta 提交于
      This can be ascertained within do_page_fault() since it gets the full
      ECR (Exception Cause Register).
      
      Further, for both the callers of do_page_fault(): Prot-V / D-TLB-Miss,
      the cause sub-fields in ECR are same for same type of access, making the
      code much more simpler.
      
      D-TLB-Miss [LD] 0x00_21_01_00
      Prot-V     [LD] 0x00_23_01_00
                              ^^
      D-TLB-Miss [ST] 0x00_21_02_00
      Prot-V     [ST] 0x00_23_02_00
                              ^^
      D-TLB-Miss [EX] 0x00_21_03_00
      Prot-V     [EX] 0x00_23_03_00
                              ^^
      
      This helps code consolidation, which is even better when moving code from
      assembler to "C".
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      3e1ae441
    • V
      ARC: Disintegrate arcregs.h · da1677b0
      Vineet Gupta 提交于
      * Move the various sub-system defines/types into relevant files/functions
        (reduces compilation time)
      
      * move CPU specific stuff out of asm/tlb.h into asm/mmu.h
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      da1677b0
  10. 09 4月, 2013 1 次提交
  11. 16 2月, 2013 1 次提交
    • V
      ARC: Page Fault handling · fbd7053a
      Vineet Gupta 提交于
      This includes recent changes to make handler "retry" and/or "killable"
      
      The killable (early exit) logic is loosely based on how SH implements it
      	return if SIGKILL + either of VM_FAULT_OOM or VM_FAULT_RETRY
      which is different from Hexagon implementation which would NOT early
      exit for
      	SIGKILL + VM_FAULT_OOM + !VM_FAULT_RETRY
      
      credits: Non executable stack support from Simon Spooner
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      fbd7053a