Eric Lee / smarc-fsl-linux-kernel

02 Feb, 2010

6 commits

01 Feb, 2010

7 commits

30 Jan, 2010

9 commits

  • 5352ae638   perf, hw_breakpoint, kgdb: Do not take mutex for kernel debugger ... Browse Code »

    This patch fixes the regression in functionality where the
    kernel debugger and the perf API do not nicely share hw
    breakpoint reservations.

    The kernel debugger cannot use any mutex_lock() calls because it
    can start the kernel running from an invalid context.

    A mutex free version of the reservation API needed to get
    created for the kernel debugger to safely update hw breakpoint
    reservations.

    The possibility for a breakpoint reservation to be concurrently
    processed at the time that kgdb interrupts the system is
    improbable. Should this corner case occur the end user is
    warned, and the kernel debugger will prohibit updating the
    hardware breakpoint reservations.

    Any time the kernel debugger reserves a hardware breakpoint it
    will be a system wide reservation.

    Signed-off-by: Jason Wessel
    Acked-by: Frederic Weisbecker
    Cc: kgdb-bugreport@lists.sourceforge.net
    Cc: K.Prasad
    Cc: Peter Zijlstra
    Cc: Alan Stern
    Cc: torvalds@linux-foundation.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jason Wessel
     
  • cc0967490   x86, hw_breakpoints, kgdb: Fix kgdb to use hw_breakpoint API ... Browse Code »

    In the 2.6.33 kernel, the hw_breakpoint API is now used for the
    performance event counters. The hw_breakpoint_handler() now
    consumes the hw breakpoints that were previously set by kgdb
    arch specific code. In order for kgdb to work in conjunction
    with this core API change, kgdb must use some of the low level
    functions of the hw_breakpoint API to install, uninstall, and
    deal with hw breakpoint reservations.

    The kgdb core required a change to call kgdb_disable_hw_debug
    anytime a slave cpu enters kgdb_wait() in order to keep all the
    hw breakpoints in sync as well as to prevent hitting a hw
    breakpoint while kgdb is active.

    During the architecture specific initialization of kgdb, it will
    pre-allocate 4 disabled (struct perf event **) structures. Kgdb
    will use these to manage the capabilities for the 4 hw
    breakpoint registers, per cpu. Right now the hw_breakpoint API
    does not have a way to ask how many breakpoints are available,
    on each CPU so it is possible that the install of a breakpoint
    might fail when kgdb restores the system to the run state. The
    intent of this patch is to first get the basic functionality of
    hw breakpoints working and leave it to the person debugging the
    kernel to understand what hw breakpoints are in use and what
    restrictions have been imposed as a result. Breakpoint
    constraints will be dealt with in a future patch.

    While atomic, the x86 specific kgdb code will call
    arch_uninstall_hw_breakpoint() and arch_install_hw_breakpoint()
    to manage the cpu specific hw breakpoints.

    The net result of these changes allow kgdb to use the same pool
    of hw_breakpoints that are used by the perf event API, but
    neither knows about future reservations for the available hw
    breakpoint slots.

    Signed-off-by: Jason Wessel
    Acked-by: Frederic Weisbecker
    Cc: kgdb-bugreport@lists.sourceforge.net
    Cc: K.Prasad
    Cc: Peter Zijlstra
    Cc: Alan Stern
    Cc: torvalds@linux-foundation.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jason Wessel
     
  • 31a090ae0   sh: Fix up asm/hw_breakpoint.h header check. ... Browse Code »

    Presently headers_check complains about linux/kdebug.h being unexported,
    so just bump the __KERNEL__ ifdef up, as per the x86 change.

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • 97b19778e   sh: mach-se: Fix up irq_desc reference. ... Browse Code »

    The irq_desc needs to be accessed with irq_to_desc(), this fixes up a
    build error with irq_desc being undefined.

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • 7c099ce15   x86: Add quirk for Intel DG45FC board to avoid low memory corruption ... Browse Code »

    Commit 6aa542a694dc9ea4344a8a590d2628c33d1b9431 added a quirk for the
    Intel DG45ID board due to low memory corruption. The Intel DG45FC
    shares the same BIOS (and the same bug) as noted in:

    http://bugzilla.kernel.org/show_bug.cgi?id=13736

    Signed-off-by: David Härdeman
    LKML-Reference:
    Cc:
    Cc: Alexey Fisher
    Cc: ykzhao
    Cc: Tony Bones
    Cc: Ingo Molnar
    Signed-off-by: H. Peter Anvin

    David Härdeman
     
  • 396c56a9c   sh: Kill off broken type 1 PCI config access checks. ... Browse Code »

    The host controllers only support type 1, so there's not much else to
    test for. Some of the older controllers also supported type 2 accesses,
    but we've never supported those, and likely never will. Beyond that, the
    P1SEG test is meaningless for 32-bit mode, so rather than refactoring it,
    just kill the type 1 test off completely.

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • 94673e968   sparc: TIF_ABI_PENDING bit removal ... Browse Code »

    Here are the sparc bits to remove TIF_ABI_PENDING now that
    set_personality() is called at the appropriate place in exec.

    Signed-off-by: David S. Miller
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    David Miller
     
  • 05d43ed8a   x86: get rid of the insane TIF_ABI_PENDING bit ... Browse Code »

    Now that the previous commit made it possible to do the personality
    setting at the point of no return, we do just that for ELF binaries.
    And suddenly all the reasons for that insane TIF_ABI_PENDING bit go
    away, and we can just make SET_PERSONALITY() just do the obvious thing
    for a 32-bit compat process.

    Everything becomes much more straightforward this way.

    Signed-off-by: H. Peter Anvin
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    H. Peter Anvin
     
  • 221af7f87   Split 'flush_old_exec' into two functions ... Browse Code »

    'flush_old_exec()' is the point of no return when doing an execve(), and
    it is pretty badly misnamed. It doesn't just flush the old executable
    environment, it also starts up the new one.

    Which is very inconvenient for things like setting up the new
    personality, because we want the new personality to affect the starting
    of the new environment, but at the same time we do _not_ want the new
    personality to take effect if flushing the old one fails.

    As a result, the x86-64 '32-bit' personality is actually done using this
    insane "I'm going to change the ABI, but I haven't done it yet" bit
    (TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
    personality, but just the "pending" bit, so that "flush_thread()" can do
    the actual personality magic.

    This patch in no way changes any of that insanity, but it does split the
    'flush_old_exec()' function up into a preparatory part that can fail
    (still called flush_old_exec()), and a new part that will actually set
    up the new exec environment (setup_new_exec()). All callers are changed
    to trivially comply with the new world order.

    Signed-off-by: H. Peter Anvin
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

29 Jan, 2010

14 commits

28 Jan, 2010

4 commits