1. 28 11月, 2009 2 次提交
  2. 04 11月, 2009 1 次提交
  3. 03 11月, 2009 1 次提交
    • R
      ARM: ensure initial page tables are setup for SMP systems · 4b46d641
      Russell King 提交于
      Mapping the same memory using two different attributes (memory
      type, shareability, cacheability) is unpredictable.  During boot,
      we encounter a situation when we're updating the kernel's page
      tables which can lead to dirty cache lines existing in the cache
      which are subsequently missed.  This causes stack corruption,
      and therefore a crash.
      
      Therefore, ensure that the shared and cacheability settings
      matches the configuration that will be used later; this together
      with the restriction in early_cachepolicy() ensures that we won't
      create a mismatch during boot.
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4b46d641
  4. 30 10月, 2009 2 次提交
  5. 26 10月, 2009 1 次提交
  6. 21 10月, 2009 1 次提交
  7. 13 10月, 2009 1 次提交
    • N
      ARM: force dcache flush if dcache_dirty bit set · 787b2faa
      Nitin Gupta 提交于
      On ARM, update_mmu_cache() does dcache flush for a page only if
      it has a kernel mapping (page_mapping(page) != NULL). The correct
      behavior would be to force the flush based on dcache_dirty bit only.
      
      One of the cases where present logic would be a problem is when
      a RAM based block device[1] is used as a swap disk. In this case,
      we would have in-memory data corruption as shown in steps below:
      
      do_swap_page()
      {
          - Allocate a new page (if not already in swap cache)
          - Issue read from swap disk
              - Block driver issues flush_dcache_page()
              - flush_dcache_page() simply sets PG_dcache_dirty bit and does not
                actually issue a flush since this page has no user space mapping yet.
          - Now, if swap disk is almost full, this newly read page is removed
            from swap cache and corrsponding swap slot is freed.
          - Map this page anonymously in user space.
          - update_mmu_cache()
              - Since this page does not have kernel mapping (its not in page/swap
                cache and is mapped anonymously), it does not issue dcache flush
                even if dcache_dirty bit is set by flush_dcache_page() above.
      
          <user now gets stale data since dcache was never flushed>
      }
      
      Same problem exists on mips too.
      
      [1] example:
       - brd (RAM based block device)
       - ramzswap (RAM based compressed swap device)
      Signed-off-by: NNitin Gupta <ngupta@vflare.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      787b2faa
  8. 11 10月, 2009 1 次提交
  9. 07 10月, 2009 2 次提交
  10. 06 10月, 2009 1 次提交
    • I
      ARM: 5742/1: ARM: add debug check for invalid kernel page faults · 1d212712
      Imre Deak 提交于
      According to the following in arch/arm/mm/fault.c page faults from
      kernel mode are invalid if mmap_sem is already held and there is
      no exception handler defined for the faulting instruction:
      
      /*
       * As per x86, we may deadlock here.  However, since the kernel only
       * validly references user space from well defined areas of the code,
       * we can bug out early if this is from code which shouldn't.
       */
      if (!down_read_trylock(&mm->mmap_sem)) {
      	if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))
      		goto no_context;
      
      Since mmap_sem can be held at arbitrary times by another thread this
      also means that any page faults from kernel mode are invalid if no
      exception handler is defined for them, regardless whether mmap_sem is
      held at the time of fault.
      
      To easier detect code that can trigger the above error, add a check
      also for the case where mmap_sem is acquired. As this has an overhead
      make it a VM debug check.
      Signed-off-by: NImre Deak <imre.deak@nokia.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1d212712
  11. 03 10月, 2009 3 次提交
  12. 29 9月, 2009 2 次提交
    • R
      ARM: Don't allow highmem on SMP platforms without h/w TLB ops broadcast · e616c591
      Russell King 提交于
      We suffer an unfortunate combination of "features" which makes highmem
      support on platforms without hardware TLB maintainence broadcast difficult:
      
      - we need kmap_high_get() support for DMA cache coherence
      - this requires kmap_high() to take a spinlock with IRQs disabled
      - kmap_high() occasionally calls flush_all_zero_pkmaps() to clear
        out old mappings
      - flush_all_zero_pkmaps() calls flush_tlb_kernel_range(), which
        on s/w IPI'd systems eventually calls smp_call_function_many()
      - smp_call_function_many() must not be called with IRQs disabled:
      
      WARNING: at kernel/smp.c:380 smp_call_function_many+0xc4/0x240()
      Modules linked in:
      Backtrace:
      [<c00306f0>] (dump_backtrace+0x0/0x108) from [<c0286e6c>] (dump_stack+0x18/0x1c)
       r6:c007cd18 r5:c02ff228 r4:0000017c
      [<c0286e54>] (dump_stack+0x0/0x1c) from [<c0053e08>] (warn_slowpath_common+0x50/0x80)
      [<c0053db8>] (warn_slowpath_common+0x0/0x80) from [<c0053e50>] (warn_slowpath_null+0x18/0x1c)
       r7:00000003 r6:00000001 r5:c1ff4000 r4:c035fa34
      [<c0053e38>] (warn_slowpath_null+0x0/0x1c) from [<c007cd18>] (smp_call_function_many+0xc4/0x240)
      [<c007cc54>] (smp_call_function_many+0x0/0x240) from [<c007cec0>] (smp_call_function+0x2c/0x38)
      [<c007ce94>] (smp_call_function+0x0/0x38) from [<c005980c>] (on_each_cpu+0x1c/0x38)
      [<c00597f0>] (on_each_cpu+0x0/0x38) from [<c0031788>] (flush_tlb_kernel_range+0x50/0x58)
       r6:00000001 r5:00000800 r4:c05f3590
      [<c0031738>] (flush_tlb_kernel_range+0x0/0x58) from [<c009c600>] (flush_all_zero_pkmaps+0xc0/0xe8)
      [<c009c540>] (flush_all_zero_pkmaps+0x0/0xe8) from [<c009c6b4>] (kmap_high+0x8c/0x1e0)
      [<c009c628>] (kmap_high+0x0/0x1e0) from [<c00364a8>] (kmap+0x44/0x5c)
      [<c0036464>] (kmap+0x0/0x5c) from [<c0109dfc>] (cramfs_readpage+0x3c/0x194)
      [<c0109dc0>] (cramfs_readpage+0x0/0x194) from [<c0090c14>] (__do_page_cache_readahead+0x1f0/0x290)
      [<c0090a24>] (__do_page_cache_readahead+0x0/0x290) from [<c0090ce4>] (ra_submit+0x30/0x38)
      [<c0090cb4>] (ra_submit+0x0/0x38) from [<c0089384>] (filemap_fault+0x3dc/0x438)
       r4:c1819988
      [<c0088fa8>] (filemap_fault+0x0/0x438) from [<c009d21c>] (__do_fault+0x58/0x43c)
      [<c009d1c4>] (__do_fault+0x0/0x43c) from [<c009e8cc>] (handle_mm_fault+0x104/0x318)
      [<c009e7c8>] (handle_mm_fault+0x0/0x318) from [<c0033c98>] (do_page_fault+0x188/0x1e4)
      [<c0033b10>] (do_page_fault+0x0/0x1e4) from [<c0033ddc>] (do_translation_fault+0x7c/0x84)
      [<c0033d60>] (do_translation_fault+0x0/0x84) from [<c002b474>] (do_DataAbort+0x40/0xa4)
       r8:c1ff5e20 r7:c0340120 r6:00000805 r5:c1ff5e54 r4:c03400d0
      [<c002b434>] (do_DataAbort+0x0/0xa4) from [<c002bcac>] (__dabt_svc+0x4c/0x60)
      ...
      
      So we disable highmem support on these systems.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e616c591
    • R
      041d785f
  13. 24 9月, 2009 1 次提交
  14. 22 9月, 2009 1 次提交
  15. 20 9月, 2009 5 次提交
  16. 16 9月, 2009 3 次提交
  17. 12 9月, 2009 1 次提交
    • R
      ARM: Fix pfn_valid() for sparse memory · b7cfda9f
      Russell King 提交于
      On OMAP platforms, some people want to declare to segment up the memory
      between the kernel and a separate application such that there is a hole
      in the middle of the memory as far as Linux is concerned.  However,
      they want to be able to mmap() the hole.
      
      This currently causes problems, because update_mmu_cache() thinks that
      there are valid struct pages for the "hole".  Fix this by making
      pfn_valid() slightly more expensive, by checking whether the PFN is
      contained within the meminfo array.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NKhasim Syed Mohammed <khasim@ti.com>
      b7cfda9f
  18. 05 9月, 2009 1 次提交
    • N
      ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem · 7929eb9c
      Nicolas Pitre 提交于
      Let's suppose a highmem page is kmap'd with kmap().  A pkmap entry is
      used, the page mapped to it, and the virtual cache is dirtied.  Then
      kunmap() is used which does virtually nothing except for decrementing a
      usage count.
      
      Then, let's suppose the _same_ page gets mapped using kmap_atomic().
      It is therefore mapped onto a fixmap entry instead, which has a
      different virtual address unaware of the dirty cache data for that page
      sitting in the pkmap mapping.
      
      Fortunately it is easy to know if a pkmap mapping still exists for that
      page and use it directly with kmap_atomic(), thanks to kmap_high_get().
      
      And actual testing with a printk in the added code path shows that this
      condition is actually met *extremely* frequently.  Seems that we've been
      quite lucky that things have worked so well with highmem so far.
      
      Cc: stable@kernel.org
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7929eb9c
  19. 02 9月, 2009 1 次提交
    • N
      ARM: 5687/1: fix an oops with highmem · 13f96d8f
      Nicolas Pitre 提交于
      In xdr_partial_copy_from_skb() there is that sequence:
      
      		kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA);
      		[...]
      		flush_dcache_page(*ppage);
      		kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA);
      
      Mixing flush_dcache_page() and kmap_atomic() is a bit odd,
      especially since kunmap_atomic() must deal with cache issues
      already.  OTOH the non-highmem case must use flush_dcache_page()
      as kunmap_atomic() becomes a no op with no cache maintenance.
      
      Problem is that with highmem the implementation of kmap_atomic()
      doesn't set page->virtual, and page_address(page) returns 0 in
      that case. Here flush_dcache_page() calls __flush_dcache_page()
      which calls __cpuc_flush_dcache_page(page_address(page)) resulting
      in a kernel oops.
      
      None of the kmap_atomic() implementations uses set_page_address().
      Hence we can assume page_address() is always expected to return 0 in
      that case. Let's conditionally call __cpuc_flush_dcache_page() only
      when the page address is non zero, and perform that test only when
      highmem is configured.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      13f96d8f
  20. 18 8月, 2009 1 次提交
  21. 15 8月, 2009 1 次提交
    • R
      ARM: Fix broken highmem support · dde5828f
      Russell King 提交于
      Currently, highmem is selectable, and you can request an increased
      vmalloc area.  However, none of this has any effect on the memory
      layout since a patch in the highmem series was accidentally dropped.
      Moreover, even if you did want highmem, all memory would still be
      registered as lowmem, possibly resulting in overflow of the available
      virtual mapping space.
      
      The highmem boundary is determined by the highest allowed beginning
      of the vmalloc area, which depends on its configurable minimum size
      (see commit 60296c71 for details on
      this).
      
      We should create mappings and initialize bootmem only for low memory,
      while the zone allocator must still be told about highmem.
      
      Currently, memory nodes which are completely located in high memory
      are not supported.  This is not a huge limitation since systems
      relying on highmem support are unlikely to have discontiguous memory
      with large holes.
      
      [ A similar patch was meant to be merged before commit 5f0fbf9e
        and be available  in Linux v2.6.30, however some git rebase screw-up
        of mine dropped the first commit of the series, and that goofage
        escaped testing somehow as well. -- Nico ]
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: NNicolas Pitre <nico@marvell.com>
      dde5828f
  22. 24 7月, 2009 7 次提交