1. 04 1月, 2006 1 次提交
    • R
      [ARM] Cleanup ARM includes · 78ff18a4
      Russell King 提交于
      arch/arm/kernel/entry-armv.S has contained a comment suggesting
      that asm/hardware.h and asm/arch/irqs.h should be moved into the
      asm/arch/entry-macro.S include.  So move the includes to these
      two files as required.
      
      Add missing includes (asm/hardware.h, asm/io.h) to asm/arch/system.h
      includes which use those facilities, and remove asm/io.h from
      kernel/process.c.
      
      Remove other unnecessary includes from arch/arm/kernel, arch/arm/mm
      and arch/arm/mach-footbridge.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      78ff18a4
  2. 01 12月, 2005 1 次提交
  3. 25 11月, 2005 1 次提交
    • R
      [ARM] Do not call flush_tlb_kernel_range() with IRQs disabled. · 5edf71ae
      Russell King 提交于
      We must not call TLB maintainence operations with interrupts disabled,
      otherwise we risk a lockup in the SMP IPI code.
      
      This means that consistent_free() can not be called from a context with
      IRQs disabled.  In addition, we must not hold the lock in consistent_free
      when we call flush_tlb_kernel_range().  However, we must continue to
      prevent consistent_alloc() from re-using the memory region until we've
      finished tearing down the mapping and dealing with the TLB.
      
      Therefore, leave the vm_region entry in the list, but mark it inactive
      before dropping the lock and starting the tear-down process.  After the
      mapping has been torn down, re-acquire the lock and remove the entry
      from the list.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5edf71ae
  4. 19 11月, 2005 1 次提交
    • D
      [ARM] 3168/1: Update ARM signal delivery and masking · a6c61e9d
      Daniel Jacobowitz 提交于
      Patch from Daniel Jacobowitz
      
      After delivering a signal (creating its stack frame) we must check for
      additional pending unblocked signals before returning to userspace.
      Otherwise signals may be delayed past the next syscall or reschedule.
      
      Once that was fixed it became obvious that the ARM signal mask manipulation
      was broken.  It was a little bit broken before the recent SA_NODEFER
      changes, and then very broken after them.  We must block the requested
      signals before starting the handler or the same signal can be delivered
      again before the handler even gets a chance to run.
      Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a6c61e9d
  5. 18 11月, 2005 2 次提交
  6. 10 11月, 2005 2 次提交
    • T
      [ARM] 3145/1: OMAP 3a/5: Add support for omap24xx · 1dbae815
      Tony Lindgren 提交于
      Patch from Tony Lindgren
      
      This patch adds support for omap24xx series of processors.
      The files live in arch/arm/mach-omap2, and share common
      files with omap15xx and omap16xx processors in
      arch/arm/plat-omap.
      
      Omap24xx support was originally added for 2.6.9 by TI.
      This code was then improved and integrated to share common
      code with omap15xx and omap16xx processors by various
      omap developers, such as Paul Mundt, Juha Yrjola, Imre Deak,
      Tony Lindgren, Richard Woodruff, Nishant Menon, Komal Shah
      et al.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1dbae815
    • T
      [ARM] 3141/1: OMAP 1/5: Update omap1 specific files · 3179a019
      Tony Lindgren 提交于
      Patch from Tony Lindgren
      
      This patch syncs the mainline kernel with linux-omap tree.
      The highlights of the patch are:
      
      - Omap1 serial pport and framebuffer init updates by Imre Deak
      
      - Add support for omap310 processor and Palm Tungsten E PDA
        by Laurent Gonzales, Romain Goyet, et al. Omap310 and
        omap1510 processors are now handled as omap15xx.
      
      - Omap1 specific changes to shared omap clock framework
        by Tony Lindgren
      
      - Omap1 specific changes to shared omap pin mux framework
        by Tony Lindgren
      
      - Other misc fixes, such as update memory timings for smc91x,
        omap1 specific device initialization etc.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3179a019
  7. 08 11月, 2005 1 次提交
  8. 07 11月, 2005 1 次提交
  9. 04 11月, 2005 1 次提交
  10. 03 11月, 2005 1 次提交
  11. 02 11月, 2005 1 次提交
  12. 31 10月, 2005 2 次提交
  13. 30 10月, 2005 4 次提交
    • H
      [PATCH] mm: split page table lock · 4c21e2f2
      Hugh Dickins 提交于
      Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
      a many-threaded application which concurrently initializes different parts of
      a large anonymous area.
      
      This patch corrects that, by using a separate spinlock per page table page, to
      guard the page table entries in that page, instead of using the mm's single
      page_table_lock.  (But even then, page_table_lock is still used to guard page
      table allocation, and anon_vma allocation.)
      
      In this implementation, the spinlock is tucked inside the struct page of the
      page table page: with a BUILD_BUG_ON in case it overflows - which it would in
      the case of 32-bit PA-RISC with spinlock debugging enabled.
      
      Splitting the lock is not quite for free: another cacheline access.  Ideally,
      I suppose we would use split ptlock only for multi-threaded processes on
      multi-cpu machines; but deciding that dynamically would have its own costs.
      So for now enable it by config, at some number of cpus - since the Kconfig
      language doesn't support inequalities, let preprocessor compare that with
      NR_CPUS.  But I don't think it's worth being user-configurable: for good
      testing of both split and unsplit configs, split now at 4 cpus, and perhaps
      change that to 8 later.
      
      There is a benefit even for singly threaded processes: kswapd can be attacking
      one part of the mm while another part is busy faulting.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4c21e2f2
    • H
      [PATCH] mm: arm ready for split ptlock · 69b04754
      Hugh Dickins 提交于
      Prepare arm for the split page_table_lock: three issues.
      
      Signal handling's preserve and restore of iwmmxt context currently involves
      reading and writing that context to and from user space, while holding
      page_table_lock to secure the user page(s) against kswapd.  If we split the
      lock, then the structure might span two pages, secured by to read into and
      write from a kernel stack buffer, copying that out and in without locking (the
      structure is 160 bytes in size, and here we're near the top of the kernel
      stack).  Or would the overhead be noticeable?
      
      arm_syscall's cmpxchg emulation use pte_offset_map_lock, instead of
      pte_offset_map and mm-wide page_table_lock; and strictly, it should now also
      take mmap_sem before descending to pmd, to guard against another thread
      munmapping, and the page table pulled out beneath this thread.
      
      Updated two comments in fault-armv.c.  adjust_pte is interesting, since its
      modification of a pte in one part of the mm depends on the lock held when
      calling update_mmu_cache for a pte in some other part of that mm.  This can't
      be done with a split page_table_lock (and we've already taken the lowest lock
      in the hierarchy here): so we'll have to disable split on arm, unless
      CONFIG_CPU_CACHE_VIPT to ensures adjust_pte never used.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69b04754
    • H
      [PATCH] mm: arches skip ptlock · b462705a
      Hugh Dickins 提交于
      Convert those few architectures which are calling pud_alloc, pmd_alloc,
      pte_alloc_map on a user mm, not to take the page_table_lock first, nor drop it
      after.  Each of these can continue to use pte_alloc_map, no need to change
      over to pte_alloc_map_lock, they're neither racy nor swappable.
      
      In the sparc64 io_remap_pfn_range, flush_tlb_range then falls outside of the
      page_table_lock: that's okay, on sparc64 it's like flush_tlb_mm, and that has
      always been called from outside of page_table_lock in dup_mmap.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b462705a
    • 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
  14. 29 10月, 2005 1 次提交
  15. 28 10月, 2005 6 次提交
  16. 20 10月, 2005 1 次提交
  17. 13 10月, 2005 1 次提交
  18. 10 10月, 2005 1 次提交
  19. 06 10月, 2005 1 次提交
  20. 03 10月, 2005 1 次提交
  21. 30 9月, 2005 2 次提交
  22. 21 9月, 2005 1 次提交
  23. 20 9月, 2005 1 次提交
  24. 10 9月, 2005 1 次提交
  25. 08 9月, 2005 1 次提交
  26. 04 9月, 2005 1 次提交
  27. 02 9月, 2005 1 次提交
  28. 01 9月, 2005 1 次提交