Doug / smarc-fsl-linux-kernel

22 Jun, 2009

1 commit

  • d06063cc2   Move FAULT_FLAG_xyz into handle_mm_fault() callers ... Browse Code »

    This allows the callers to now pass down the full set of FAULT_FLAG_xyz
    flags to handle_mm_fault(). All callers have been (mechanically)
    converted to the new calling convention, there's almost certainly room
    for architectures to clean up their code and then add FAULT_FLAG_RETRY
    when that support is added.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

19 Jun, 2009

1 commit

  • b99c6ebe8   sparc64: Fix UP bootup regression. ... Browse Code »

    Commit b696fdc259f0d94348a9327bed352fac44d4883d ("sparc64: Defer
    cpu_data() setup until end of per-cpu data initialization.") broke
    bootup for UP builds because the cpu_data() initialization only
    occurs in setup_per_cpu_areas() which is never compiled in nor
    called in UP builds.

    Fix this up by calling the setups directly from init_64.c when
    non-SMP.

    Reported-by: Alexander Beregalov
    Tested-by: Alexander Beregalov
    Signed-off-by: David S. Miller

    David S. Miller
     

16 Jun, 2009

6 commits

12 Jun, 2009

1 commit

  • ad6561dff   module: trim exception table on init free. ... Browse Code »

    It's theoretically possible that there are exception table entries
    which point into the (freed) init text of modules. These could cause
    future problems if other modules get loaded into that memory and cause
    an exception as we'd see the wrong fixup. The only case I know of is
    kvm-intel.ko (when CONFIG_CC_OPTIMIZE_FOR_SIZE=n).

    Amerigo fixed this long-standing FIXME in the x86 version, but this
    patch is more general.

    This implements trim_init_extable(); most archs are simple since they
    use the standard lib/extable.c sort code. Alpha and IA64 use relative
    addresses in their fixups, so thier trimming is a slight variation.

    Sparc32 is unique; it doesn't seem to define ARCH_HAS_SORT_EXTABLE,
    yet it defines its own sort_extable() which overrides the one in lib.
    It doesn't sort, so we have to mark deleted entries instead of
    actually trimming them.

    Inspired-by: Amerigo Wang
    Signed-off-by: Rusty Russell
    Cc: linux-alpha@vger.kernel.org
    Cc: sparclinux@vger.kernel.org
    Cc: linux-ia64@vger.kernel.org

    Rusty Russell
     

08 Apr, 2009

2 commits

01 Apr, 2009

1 commit

  • 7ca43e756   mm: use debug_kmap_atomic ... Browse Code »

    Use debug_kmap_atomic in kmap_atomic, kmap_atomic_pfn, and
    iomap_atomic_prot_pfn.

    Signed-off-by: Akinobu Mita
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

30 Mar, 2009

1 commit

19 Mar, 2009

1 commit

16 Mar, 2009

2 commits

04 Feb, 2009

1 commit

  • 9b0260582   sparc64: Kill bogus TPC/address truncation during 32-bit faults. ... Browse Code »

    This builds upon eeabac7386ca13bfe1a58afeb04326a9e1a3a20e
    ("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: David S. Miller

    David S. Miller
     

03 Feb, 2009

1 commit

  • eeabac738   sparc64: Validate kernel generated fault addresses on sparc64. ... Browse Code »

    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: David S. Miller

    David S. Miller
     

09 Jan, 2009

2 commits

  • 917c3660d   sparc64: move EXPORT_SYMBOL to the symbols definition ... Browse Code »

    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: Sam Ravnborg

    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: Julian Calaby
    Signed-off-by: David S. Miller

    Sam Ravnborg
     
  • 6943f3da3   sparc: move EXPORT_SYMBOL to the symbols definition ... Browse Code »

    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: Sam Ravnborg

    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: Julian Calaby
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

07 Jan, 2009

3 commits

  • 901811364   sparc64: Use unsigned long long for u64. ... Browse Code »

    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: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Sam Ravnborg
     
  • 0157141ae   sparc: refactor code in fault_32.c ... Browse Code »

    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: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     
  • ff9aefbf4   sparc64: refactor code in init_64.c ... Browse Code »

    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: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

27 Dec, 2008

2 commits

  • c4a4a2197   sparc: drop SUN_IO ... Browse Code »

    SUN_IO is always 'y' so drop it and thus killing an ifdef/endif pair

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     
  • 86ed40bd6   sparc: unify sections.h ... Browse Code »

    While doing this use standard names for start/end
    so we could use definitions straight from asm-generic
    for all the typical symbols.

    This also allowed us to drop the use of PROVIDE in the linker
    script so sprc is less non-standard on this area.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

12 Dec, 2008

1 commit

  • aa83a26a1   sparc: use sparc64 version of scatterlist.h ... Browse Code »

    Use sparc64 version of scatterlist.h.

    There are three main differences:
    dma_addr_t replaces __u32
    dma_address replaces dvma_address
    dma_length replaces dvma_length

    dma_addr_t is a u32 on sparc32.

    Boot tested on sparc32.

    Signed-off-by: Robert Reif
    Signed-off-by: David S. Miller

    Robert Reif
     

05 Dec, 2008

6 commits

01 Dec, 2008

1 commit

  • 409832f54   sparc32 cpuinit flase positives ... Browse Code »

    All noise since we don't have CPU hotplug there. However, they
    did expose something very odd-looking in there - poke_viking()
    does a bunch of identical btfixup each time it's called (i.e.
    for each CPU). That one is left alone for now; just the trivial
    misannotation fixes.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

04 Sep, 2008

1 commit

02 Sep, 2008

1 commit

01 Sep, 2008

1 commit

  • 5110bd21b   sparc: remove CONFIG_SUN4 ... Browse Code »

    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: Adrian Bunk
    Signed-off-by: David S. Miller

    Adrian Bunk
     

29 Aug, 2008

4 commits