1. 19 3月, 2009 1 次提交
  2. 16 3月, 2009 2 次提交
  3. 04 2月, 2009 1 次提交
    • D
      sparc64: Kill bogus TPC/address truncation during 32-bit faults. · 9b026058
      David S. Miller 提交于
      This builds upon eeabac73
      ("sparc64: Validate kernel generated fault addresses on sparc64.")
      
      Upon further consideration, we actually should never see any
      fault addresses for 32-bit tasks with the upper 32-bits set.
      
      If it does every happen, by definition it's a bug.  Whatever
      context created that fault would only have that fault satisfied
      if we used the full 64-bit address.  If we truncate it, we'll
      always fault the wrong address and we'll always loop faulting
      forever.
      
      So catch such conditions and mark them as errors always.  Log
      the error and fail the fault.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b026058
  4. 03 2月, 2009 1 次提交
    • D
      sparc64: Validate kernel generated fault addresses on sparc64. · eeabac73
      David S. Miller 提交于
      In order to handle all of the cases of address calculation overflow
      properly, we run sparc 32-bit processes in "address masking" mode
      when running on a 64-bit kernel.
      
      Address masking mode zeros out the top 32-bits of the address
      calculated for every load and store instruction.
      
      However, when we're in privileged mode we have to run with that
      address masking mode disabled even when accessing userspace from
      the kernel.
      
      To "simulate" the address masking mode we clear the top-bits by
      hand for 32-bit processes in the fault handler.
      
      It is the responsibility of code in the compat layer to properly
      zero extend addresses used to access userspace.  If this isn't
      followed properly we can get into a fault loop.
      
      Say that the user address is 0xf0000000 but for whatever reason
      the kernel code sign extends this to 64-bit, and then the kernel
      tries to access the result.
      
      In such a case we'll fault on address 0xfffffffff0000000 but the fault
      handler will process that fault as if it were to address 0xf0000000.
      We'll loop faulting forever because the fault never gets satisfied.
      
      So add a check specifically for this case, when the kernel is faulting
      on a user address access and the addresses don't match up.
      
      This code path is sufficiently slow path, and this bug is sufficiently
      painful to diagnose, that this kind of bug check is warranted.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eeabac73
  5. 09 1月, 2009 2 次提交
    • S
      sparc64: move EXPORT_SYMBOL to the symbols definition · 917c3660
      Sam Ravnborg 提交于
      Move all applicable EXPORT_SYMBOL()s to the file where the respective
      symbol is defined.
      
      Removed all the includes that are no longer needed in sparc_ksyms_64.c
      
      Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_64.c
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      
      Additions by Julian Calaby:
      * Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
      * Made some minor cleanups to the includes and comments of sparc_ksyms_64.c
      * Updated and tidied commit message.
      * Rebased patch over sparc-2.6.git HEAD.
      * Ensured that all modified files have the correct includes.
      Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      917c3660
    • S
      sparc: move EXPORT_SYMBOL to the symbols definition · 6943f3da
      Sam Ravnborg 提交于
      Move all applicable EXPORT_SYMBOL()s to the file where the respective
      symbol is defined.
      
      Removed all the includes that are no longer needed in sparc_ksyms_32.c
      
      Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_32.c
      
      Two symbols are shared with sparc64 thus the exports were removed from
      the sparc_ksyms_64.c too, along with the include their ommission made
      redundant.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      
      Additions by Julian Calaby:
      * Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
      * Made some minor cleanups to the includes and comments of sparc_ksyms_32.c
      * Made another subtraction from sparc_ksyms_64.c
      * Updated and tidied commit message.
      * Rebased patch over sparc-2.6.git HEAD.
      * Ensured that all modified files have the correct includes.
      Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6943f3da
  6. 07 1月, 2009 3 次提交
    • S
      sparc64: Use unsigned long long for u64. · 90181136
      Sam Ravnborg 提交于
      Andrew Morton wrote:
      
          People keep on doing
      
                  printk("%llu", some_u64);
      
          testing it only on x86_64 and this generates a warning storm on
          powerpc, sparc64, etc.  Because they use `long', not `long long'.
      
          Quite a few 64-bit architectures are using `long' for their
          s64/u64 types.  We should convert them all to `long long'.
      
      Update types.h so we use unsigned long long for u64 and
      fix all warnings in sparc64 code.
      Tested with an allnoconfig, defconfig and allmodconfig builds.
      
      This patch introduces additional warnings in several drivers.
      These will be dealt with in separate patches.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90181136
    • S
      sparc: refactor code in fault_32.c · 0157141a
      Sam Ravnborg 提交于
      The sparc allmodconfig build broke due to enabling of the
      branch_tracer that does some very clever things with
      all if conditions. This caused my gcc 3.4.5 to be so confused that
      it emitted a warning:
      
      arch/sparc/mm/fault_32.c: In function `do_sparc_fault':
      arch/sparc/mm/fault_32.c:176: warning: 'fixup' might be used uninitialized in this function
      
      And with -Werror this broke the build.
      
      Refactor code so it:
      1) becomes more readable
      2) no longer emit a warning with the branch_tracer enabled
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0157141a
    • S
      sparc64: refactor code in init_64.c · ff9aefbf
      Sam Ravnborg 提交于
      The sparc64 allmodconfig build broke due to enabling of the
      branch_tracer that does some very clever things with
      all if conditions. This caused my gcc 3.4.5 to be so confused that
      it emitted two warnings:
      
      arch/sparc/mm/init_64.c: In function `update_mmu_cache':
      arch/sparc/mm/init_64.c:271: warning: 'pg_flags' might be used uninitialized in this function
      arch/sparc/mm/init_64.c:272: warning: 'page' might be used uninitialized in this function
      
      And with -Werror this broke the build.
      
      Refactor code so it:
      1) becomes more readable
      2) no longer emit a warning with the branch_tracer enabled
      
      The refactoring uses a small helper function (flush_dcache()).
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff9aefbf
  7. 27 12月, 2008 2 次提交
  8. 12 12月, 2008 1 次提交
  9. 05 12月, 2008 6 次提交
  10. 01 12月, 2008 1 次提交
  11. 04 9月, 2008 1 次提交
  12. 02 9月, 2008 1 次提交
  13. 01 9月, 2008 1 次提交
    • A
      sparc: remove CONFIG_SUN4 · 5110bd21
      Adrian Bunk 提交于
      While doing some easy cleanups on the sparc code I noticed that the
      CONFIG_SUN4 code seems to be worse than the rest - there were some
      "I don't know how it should work, but the current code definitely cannot
      work." places.
      
      And while I have seen people running Linux on machines like a
      SPARCstation 5 a few years ago I don't recall having seen sun4
      machines, even less ones running Linux.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5110bd21
  14. 29 8月, 2008 7 次提交
  15. 25 7月, 2008 1 次提交
  16. 18 7月, 2008 2 次提交
    • R
      sparc32: fix init.c allnoconfig build error · f538f3df
      Robert Reif 提交于
      Fix allnoconfig build error.
      Signed-off-by: NRobert Reif <reif@earthlink.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f538f3df
    • A
      sparc/mm/: possible cleanups · 50215d65
      Adrian Bunk 提交于
      This patch contains the following possible cleanups:
      - make the following needlessly global code static:
        - fault.c: force_user_fault()
        - init.c: calc_max_low_pfn()
        - init.c: pgt_cache_water[]
        - init.c: map_high_region()
        - srmmu.c: hwbug_bitmask
        - srmmu.c: srmmu_swapper_pg_dir
        - srmmu.c: srmmu_context_table
        - srmmu.c: is_hypersparc
        - srmmu.c: srmmu_cache_pagetables
        - srmmu.c: srmmu_nocache_size
        - srmmu.c: srmmu_nocache_end
        - srmmu.c: srmmu_get_nocache()
        - srmmu.c: srmmu_free_nocache()
        - srmmu.c: srmmu_early_allocate_ptable_skeleton()
        - srmmu.c: srmmu_nocache_calcsize()
        - srmmu.c: srmmu_nocache_init()
        - srmmu.c: srmmu_alloc_thread_info()
        - srmmu.c: early_pgtable_allocfail()
        - srmmu.c: srmmu_early_allocate_ptable_skeleton()
        - srmmu.c: srmmu_allocate_ptable_skeleton()
        - srmmu.c: srmmu_inherit_prom_mappings()
        - sunami.S: tsunami_copy_1page
      - remove the following unused code:
        - init.c: struct sparc_aliases
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50215d65
  17. 20 5月, 2008 1 次提交
  18. 02 5月, 2008 2 次提交
  19. 13 2月, 2008 1 次提交
  20. 09 2月, 2008 2 次提交
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f569afd
    • D
      aout: remove unnecessary inclusions of {asm, linux}/a.out.h · 1eb11411
      David Howells 提交于
      Remove now unnecessary inclusions of {asm,linux}/a.out.h.
      
      [akpm@linux-foundation.org: fix alpha build]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eb11411
  21. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39