1. 20 10月, 2007 1 次提交
    • S
      pid namespaces: define is_global_init() and is_container_init() · b460cbc5
      Serge E. Hallyn 提交于
      is_init() is an ambiguous name for the pid==1 check.  Split it into
      is_global_init() and is_container_init().
      
      A cgroup init has it's tsk->pid == 1.
      
      A global init also has it's tsk->pid == 1 and it's active pid namespace
      is the init_pid_ns.  But rather than check the active pid namespace,
      compare the task structure with 'init_pid_ns.child_reaper', which is
      initialized during boot to the /sbin/init process and never changes.
      
      Changelog:
      
      	2.6.22-rc4-mm2-pidns1:
      	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
      	  global init (/sbin/init) process. This would improve performance
      	  and remove dependence on the task_pid().
      
      	2.6.21-mm2-pidns2:
      
      	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
      	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
      	  This way, we kill only the cgroup if the cgroup's init has a
      	  bug rather than force a kernel panic.
      
      [akpm@linux-foundation.org: fix comment]
      [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
      [bunk@stusta.de: kernel/pid.c: remove unused exports]
      [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b460cbc5
  2. 17 10月, 2007 1 次提交
    • W
      During VM oom condition, kill all threads in process group · dcca2bde
      Will Schmidt 提交于
      We have had complaints where a threaded application is left in a bad state
      after one of it's threads is killed when we hit a VM: out_of_memory
      condition.
      
      Killing just one of the process threads can leave the application in a bad
      state, whereas killing the entire process group would allow for the
      application to restart, or be otherwise handled, and makes it very obvious
      that something has gone wrong.
      
      This change allows the entire process group to be taken down, rather
      than just the one thread.
      Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dcca2bde
  3. 17 9月, 2007 1 次提交
  4. 20 7月, 2007 1 次提交
    • N
      mm: fault feedback #2 · 83c54070
      Nick Piggin 提交于
      This patch completes Linus's wish that the fault return codes be made into
      bit flags, which I agree makes everything nicer.  This requires requires
      all handle_mm_fault callers to be modified (possibly the modifications
      should go further and do things like fault accounting in handle_mm_fault --
      however that would be for another patch).
      
      [akpm@linux-foundation.org: fix alpha build]
      [akpm@linux-foundation.org: fix s390 build]
      [akpm@linux-foundation.org: fix sparc build]
      [akpm@linux-foundation.org: fix sparc64 build]
      [akpm@linux-foundation.org: fix ia64 build]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Still apparently needs some ARM and PPC loving - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83c54070
  5. 10 7月, 2007 1 次提交
  6. 23 5月, 2007 2 次提交
    • K
      [PPC] Fix modpost warning · c1c9889a
      Kumar Gala 提交于
      Mark pte_alloc_one_kernel as __init_refok to fix the following warning:
      
      WARNING: arch/ppc/mm/built-in.o(.text+0x1114): Section mismatch: reference to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'v_mapped_by_tlbcam')
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      c1c9889a
    • K
      [PPC] Fix COMMON symbol warnings · 9c05e63e
      Kumar Gala 提交于
      We get the following warnings in various ARCH=ppc builds:
      
      WARNING: "ee_restarts" [arch/ppc/kernel/built-in] is COMMON symbol
      WARNING: "fee_restarts" [arch/ppc/kernel/built-in] is COMMON symbol
      WARNING: "htab_hash_searches" [arch/ppc/mm/built-in] is COMMON symbol
      WARNING: "next_slot" [arch/ppc/mm/built-in] is COMMON symbol
      WARNING: "mmu_hash_lock" [arch/ppc/mm/built-in] is COMMON symbol
      WARNING: "primary_pteg_full" [arch/ppc/mm/built-in] is COMMON symbol
      WARNING: "global_dbcr0" [arch/ppc/kernel/built-in] is COMMON symbol
      
      Switch to local symbols for ee_restarts, fee_restarts, and global_dbcr0 and
      global symbols for mmu_hash_lock, next_slot, primary_pteg_full, and
      htab_hash_searches.
      
      (except mmu_hash_lock which is global) and
      space directive instead.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      9c05e63e
  7. 12 5月, 2007 1 次提交
  8. 09 2月, 2007 1 次提交
    • K
      [POWERPC] Fix is_power_of_4(x) compile error · 8dabba5d
      Kumar Gala 提交于
      When building an 85xx kernel we get:
      
        CC      arch/powerpc/mm/pgtable_32.o
      arch/powerpc/mm/pgtable_32.c: In function 'io_block_mapping':
      arch/powerpc/mm/pgtable_32.c:330: error: expected identifier before '(' token
      arch/powerpc/mm/pgtable_32.c:330: error: expected statement before ')' token
      
      The is_power_of_2(x) fixup patch left an extra ')' on the is_power_of_4 macro.
      There is a similiar issue on the arch/ppc side.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      8dabba5d
  9. 07 2月, 2007 1 次提交
  10. 12 10月, 2006 1 次提交
    • M
      [PATCH] mm: use symbolic names instead of indices for zone initialisation · 6391af17
      Mel Gorman 提交于
      Arch-independent zone-sizing is using indices instead of symbolic names to
      offset within an array related to zones (max_zone_pfns).  The unintended
      impact is that ZONE_DMA and ZONE_NORMAL is initialised on powerpc instead
      of ZONE_DMA and ZONE_HIGHMEM when CONFIG_HIGHMEM is set.  As a result, the
      the machine fails to boot but will boot with CONFIG_HIGHMEM turned off.
      
      The following patch properly initialises the max_zone_pfns[] array and uses
      symbolic names instead of indices in each architecture using
      arch-independent zone-sizing.  Two users have successfully booted their
      powerpcs with it (one an ibook G4).  It has also been boot tested on x86,
      x86_64, ppc64 and ia64.  Please merge for 2.6.19-rc2.
      
      Credit to Benjamin Herrenschmidt for identifying the bug and rolling the
      first fix.  Additional credit to Johannes Berg and Andreas Schwab for
      reporting the problem and testing on powerpc.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6391af17
  11. 30 9月, 2006 2 次提交
    • S
      [PATCH] pidspace: is_init() · f400e198
      Sukadev Bhattiprolu 提交于
      This is an updated version of Eric Biederman's is_init() patch.
      (http://lkml.org/lkml/2006/2/6/280).  It applies cleanly to 2.6.18-rc3 and
      replaces a few more instances of ->pid == 1 with is_init().
      
      Further, is_init() checks pid and thus removes dependency on Eric's other
      patches for now.
      
      Eric's original description:
      
      	There are a lot of places in the kernel where we test for init
      	because we give it special properties.  Most  significantly init
      	must not die.  This results in code all over the kernel test
      	->pid == 1.
      
      	Introduce is_init to capture this case.
      
      	With multiple pid spaces for all of the cases affected we are
      	looking for only the first process on the system, not some other
      	process that has pid == 1.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: <lxc-devel@lists.sourceforge.net>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f400e198
    • J
      [PATCH] make PROT_WRITE imply PROT_READ · df67b3da
      Jason Baron 提交于
      Make PROT_WRITE imply PROT_READ for a number of architectures which don't
      support write only in hardware.
      
      While looking at this, I noticed that some architectures which do not
      support write only mappings already take the exact same approach.  For
      example, in arch/alpha/mm/fault.c:
      
      "
              if (cause < 0) {
                      if (!(vma->vm_flags & VM_EXEC))
                              goto bad_area;
              } else if (!cause) {
                      /* Allow reads even for write-only mappings */
                      if (!(vma->vm_flags & (VM_READ | VM_WRITE)))
                              goto bad_area;
              } else {
                      if (!(vma->vm_flags & VM_WRITE))
                              goto bad_area;
              }
      "
      
      Thus, this patch brings other architectures which do not support write only
      mappings in-line and consistent with the rest.  I've verified the patch on
      ia64, x86_64 and x86.
      
      Additional discussion:
      
      Several architectures, including x86, can not support write-only mappings.
      The pte for x86 reserves a single bit for protection and its two states are
      read only or read/write.  Thus, write only is not supported in h/w.
      
      Currently, if i 'mmap' a page write-only, the first read attempt on that page
      creates a page fault and will SEGV.  That check is enforced in
      arch/blah/mm/fault.c.  However, if i first write that page it will fault in
      and the pte will be set to read/write.  Thus, any subsequent reads to the page
      will succeed.  It is this inconsistency in behavior that this patch is
      attempting to address.  Furthermore, if the page is swapped out, and then
      brought back the first read will also cause a SEGV.  Thus, any arbitrary read
      on a page can potentially result in a SEGV.
      
      According to the SuSv3 spec, "if the application requests only PROT_WRITE, the
      implementation may also allow read access." Also as mentioned, some
      archtectures, such as alpha, shown above already take the approach that i am
      suggesting.
      
      The counter-argument to this raised by Arjan, is that the kernel is enforcing
      the write only mapping the best it can given the h/w limitations.  This is
      true, however Alan Cox, and myself would argue that the inconsitency in
      behavior, that is applications can sometimes work/sometimes fails is highly
      undesireable.  If you read through the thread, i think people, came to an
      agreement on the last patch i posted, as nobody has objected to it...
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NAndi Kleen <ak@muc.de>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Ian Molton <spyro@f2s.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      df67b3da
  12. 27 9月, 2006 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 13 6月, 2006 1 次提交
  15. 11 6月, 2006 1 次提交
  16. 29 3月, 2006 1 次提交
  17. 28 3月, 2006 1 次提交
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      Paul Mackerras 提交于
      32-bit CHRP machines are now supported only in arch/powerpc, as are
      all 64-bit PowerPC processors.  This means that we don't use
      Open Firmware on any platform in arch/ppc any more.
      
      This makes PReP support a single-platform option like every other
      platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
      is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
      PReP support and is generally what has replaced
      CONFIG_PPC_MULTIPLATFORM within arch/ppc.
      
      _machine is all but dead now, being #defined to 0.
      
      Updated Makefiles, comments and Kconfig options generally to reflect
      these changes.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  18. 22 3月, 2006 1 次提交
  19. 10 2月, 2006 1 次提交
  20. 20 1月, 2006 1 次提交
  21. 15 1月, 2006 1 次提交
    • P
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      Paul Mackerras 提交于
      This makes it possible to build kernels for PReP and/or CHRP
      with ARCH=ppc by removing the (non-building) powermac support.
      It's now also possible to select PReP and CHRP independently.
      Powermac users should now build with ARCH=powerpc instead of
      ARCH=ppc.  (This does mean that it is no longer possible to
      build a 32-bit kernel for a G5.)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7fdd90b
  22. 16 11月, 2005 1 次提交
    • M
      [PATCH] ppc32 8xx: update_mmu_cache() needs unconditional tlbie · eb07d964
      Marcelo Tosatti 提交于
      Currently 8xx fails to boot due to endless pagefaults.
      
      Seems the bug is exposed by the change which avoids flushing the
      TLB when not necessary (in case the pte has not changed), introduced
      recently:
      
      __handle_mm_fault():
      
              entry = pte_mkyoung(entry);
              if (!pte_same(old_entry, entry)) {
                      ptep_set_access_flags(vma, address, pte, entry, write_access);
                      update_mmu_cache(vma, address, entry);
                      lazy_mmu_prot_update(entry);
              } else {
                      /*
                       * This is needed only for protection faults but the arch code
                       * is not yet telling us if this is a protection fault or not.
                       * This still avoids useless tlb flushes for .text page faults
                       * with threads.
                       */
                      if (write_access)
                              flush_tlb_page(vma, address);
              }
      
      The "update_mmu_cache()" call was unconditional before, which caused the TLB
      to be flushed by:
      
              if (pfn_valid(pfn)) {
                      struct page *page = pfn_to_page(pfn);
                      if (!PageReserved(page)
                          && !test_bit(PG_arch_1, &page->flags)) {
                              if (vma->vm_mm == current->active_mm) {
      #ifdef CONFIG_8xx
                              /* On 8xx, cache control instructions (particularly 
                               * "dcbst" from flush_dcache_icache) fault as write 
                               * operation if there is an unpopulated TLB entry 
                               * for the address in question. To workaround that, 
                               * we invalidate the TLB here, thus avoiding dcbst 
                               * misbehaviour.
                               */
                                      _tlbie(address);
      #endif
                                      __flush_dcache_icache((void *) address);
                              } else
                                      flush_dcache_icache_page(page);
                              set_bit(PG_arch_1, &page->flags);
                      }
      
      Which worked to due to pure luck: PG_arch_1 was always unset before, but
      now it isnt.
      
      The root of the problem are the changes against the 8xx TLB handlers introduced
      during v2.6. What happens is the TLBMiss handlers load the zeroed pte into
      the TLB, causing the TLBError handler to be invoked (thats two TLB faults per 
      pagefault), which then jumps to the generic MM code to setup the pte.
      
      The bug is that the zeroed TLB is not invalidated (the same reason
      for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
      
      The "two exception" approach requires a TLB flush (to nuke the zeroed TLB)
      at each PTE update for correct behaviour:
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      eb07d964
  23. 14 11月, 2005 1 次提交
  24. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: init_mm without ptlock · 872fec16
      Hugh Dickins 提交于
      First step in pushing down the page_table_lock.  init_mm.page_table_lock has
      been used throughout the architectures (usually for ioremap): not to serialize
      kernel address space allocation (that's usually vmlist_lock), but because
      pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it.
      
      Reverse that: don't lock or unlock init_mm.page_table_lock in any of the
      architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take
      and drop it when allocating a new one, to check lest a racing task already
      did.  Similarly no page_table_lock in vmalloc's map_vm_area.
      
      Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle
      user mms, which are converted only by a later patch, for now they have to lock
      differently according to whether or not it's init_mm.
      
      If sources get muddled, there's a danger that an arch source taking
      init_mm.page_table_lock will be mixed with common source also taking it (or
      neither take it).  So break the rules and make another change, which should
      break the build for such a mismatch: remove the redundant mm arg from
      pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13).
      
      Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64
      used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to
      pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64
      map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free
      took page_table_lock for no good reason.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      872fec16
  25. 29 10月, 2005 1 次提交
    • R
      [PATCH] ppc: make phys_mem_access_prot() work with pfns instead of addresses · 8b150478
      Roland Dreier 提交于
      Change the phys_mem_access_prot() function to take a pfn instead of an
      address.  This allows mmap64() to work on /dev/mem for addresses above 4G
      on 32-bit architectures.  We start with a pfn in mmap_mem(), so there's no
      need to convert to an address; in fact, it's actively bad, since the
      conversion can overflow when the address is above 4G.
      
      Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an
      address by directly comparing to max_pfn.  Working with max_pfn instead of
      high_memory fixes page_is_ram() to give the right answer for highmem pages.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8b150478
  26. 28 10月, 2005 1 次提交
  27. 22 10月, 2005 1 次提交
  28. 19 9月, 2005 1 次提交
  29. 11 9月, 2005 1 次提交
    • P
      [PATCH] ppc32: Kill init on unhandled synchronous signals · bb0bb3b6
      Paul Mackerras 提交于
      This is a patch that I have had in my tree for ages.  If init causes
      an exception that raises a signal, such as a SIGSEGV, SIGILL or
      SIGFPE, and it hasn't registered a handler for it, we don't deliver
      the signal, since init doesn't get any signals that it doesn't have a
      handler for.  But that means that we just return to userland and
      generate the same exception again immediately.  With this patch we
      print a message and kill init in this situation.
      
      This is very useful when you have a bug in the kernel that means that
      init doesn't get as far as executing its first instruction. :)
      Without this patch the system hangs when it gets to starting the
      userland init; with it you at least get a message giving you a clue
      about what has gone wrong.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb0bb3b6
  30. 10 9月, 2005 1 次提交
  31. 05 9月, 2005 2 次提交
  32. 28 7月, 2005 1 次提交
    • A
      [PATCH] ppc32: 8xx avoid icbi misbehaviour in __flush_dcache_icache_phys · bf85fa6c
      Anton Wllert 提交于
      On 8xx, in the case where a pagefault happens for a process who's not
      the owner of the vma in question (ptrace for instance), the flush
      operation is performed via the physical address.
      
      Unfortunately, that results in a strange, unexplainable "icbi"
      instruction fault, most likely due to a CPU bug (see oops below).
      
      Avoid that by flushing the page via its kernel virtual address.
      
      Oops: kernel access of bad area, sig: 11 [#2]
      NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tainted
      MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
      DAR: 00000010, DSISR: C2000000
      TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
      Last syscall: 26
      GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
      00000001
      GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
      00000001
      GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
      C01E0000
      GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
      C02ACB00
      NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
      LR [c000b060] flush_dcache_icache_page+0x20/0x30
      Call trace:
      [c000b154] update_mmu_cache+0x7c/0xa4
      [c005ae98] do_wp_page+0x460/0x5ec
      [c005c8a0] handle_mm_fault+0x7cc/0x91c
      [c005ccec] get_user_pages+0x2fc/0x65c
      [c0027104] access_process_vm+0x9c/0x1d4
      [c00076e0] sys_ptrace+0x240/0x4a4
      [c0002bd0] ret_from_syscall+0x0/0x44
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bf85fa6c
  33. 28 6月, 2005 1 次提交
    • M
      [PATCH] 8xx: avoid "dcbst" misbehaviour with unpopulated TLB · bb165746
      Marcelo Tosatti 提交于
      The proposed _tlbie call at update_mmu_cache() is safe because:
      
      Addresses for which update_mmu_cache() gets invocated are never inside the
      static kernel virtual mapping, meaning that there is no risk for the
      _tlbie() here to be thrashing the pinned entry, as Dan suspected.
      
      The intermediate TLB state in which this bug can be triggered is not
      visible by userspace or any other contexts, except the page fault handling
      path.  So there is no need to worry about userspace dcbxxx users.
      
      The other solution to this is to avoid dcbst misbehaviour in the first
      place, which involves changing in-kernel "dcbst" callers to use 8xx
      specific SPR's.
      
      Summary:
      
      On 8xx, cache control instructions (particularly "dcbst" from
      flush_dcache_icache) fault as write operation if there is an unpopulated
      TLB entry for the address in question.  To workaround that, we invalidate
      the TLB here, thus avoiding dcbst misbehaviour.
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb165746
  34. 26 6月, 2005 2 次提交
  35. 22 6月, 2005 2 次提交