Eric Lee / smarc-fsl-linux-kernel

01 Jul, 2011

1 commit

  • a8b0ca17b   perf: Remove the nmi parameter from the swevent and overflow interface ... Browse Code »
    1

    The nmi parameter indicated if we could do wakeups from the current
    context, if not, we would set some state and self-IPI and let the
    resulting interrupt do the wakeup.

    For the various event classes:

    - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
    - tracepoint: nmi=0; since tracepoint could be from NMI context.
    - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

    As one can see, there is very little nmi=1 usage, and the down-side of
    not using it is that on some platforms some software events can have a
    jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

    The up-side however is that we can remove the nmi parameter and save a
    bunch of conditionals in fast paths.

    Signed-off-by: Peter Zijlstra
    Cc: Michael Cree
    Cc: Will Deacon
    Cc: Deng-Cheng Zhu
    Cc: Anton Blanchard
    Cc: Eric B Munson
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: David S. Miller
    Cc: Frederic Weisbecker
    Cc: Jason Wessel
    Cc: Don Zickus
    Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

01 Mar, 2010

1 commit

21 Jan, 2010

1 commit

11 Dec, 2009

2 commits

03 Aug, 2009

1 commit

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
     

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
     

05 Dec, 2008

1 commit

  • 27137e528   sparc,sparc64: unify mm/ ... Browse Code »

    - move all sparc64/mm/ files to arch/sparc/mm/
    - commonly named files are named _64.c
    - add files to sparc/mm/Makefile preserving link order
    - delete now unused sparc64/mm/Makefile
    - sparc64 now finds mm/ in sparc

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

    Sam Ravnborg