Re: [PATCH 3.18-rc3 v8 0/4] arm: Implement arch_trigger_all_cpu_backtrace

[Daniel Thompson]

On 14/11/14 12:35, Daniel Thompson wrote:
> Hi Thomas, Hi Jason,
> 
>   [Today I was *planning* to ask if patches 1 & 2 are OK for the irqchip
>   tree. However just to be on the safe side I ran some build tests and
>   they picked up something I overlooked last time. So instead of a poke
>   I've put out a new patchset instead. Just to be sure I ran some build
>   tests on the just patch 1 & 2 on their own. I couldn't find any
>   mid-series build regressions so taking just the first two patches
>   should present no problems.]

Are there any comments on patches 1 & 2?


Daniel.

> 
> This patchset modifies the GIC driver to allow it, on supported
> platforms, to route IPI interrupts to FIQ and uses this feature to
> implement arch_trigger_all_cpu_backtrace for arm.
> 
> On platforms not capable of supporting FIQ the signal to generate a
> backtrace we fall back to using IRQ for propagation instead (relying on
> a timeout to avoid wedging the CPU requesting the backtrace if other
> CPUs are not responsive).
> 
> It has been tested on two systems capable of supporting grouping
> (Freescale i.MX6 and STiH416) and two that do not (vexpress-a9 and
> Qualcomm Snapdragon 600).
> 
> v8:
> 
> * Fixed build on arm64 causes by a spurious include file in irq-gic.c.
> 
> v7-2 (accidentally released twice with same number):
> 
> * Fixed boot regression on vexpress-a9 (reported by Russell King).
> 
> * Rebased on v3.18-rc3; removed one patch from set that is already
>   included in mainline.
> 
> * Dropped arm64/fiq.h patch from the set (still useful but not related
>   to issuing backtraces).
> 
> v7:
> 
> * Re-arranged code within the patch series to fix a regression
>   introduced midway through the series and corrected by a later patch
>   (testing by Olof's autobuilder). Tested offending patch in isolation
>   using defconfig identified by the autobuilder.
> 
> v6:
> 
> * Renamed svc_entry's call_trace argument to just trace (example code
>   from Russell King).
> 
> * Fixed mismatched ENDPROC() in __fiq_abt (example code from Russell
>   King).
> 
> * Modified usr_entry to optional avoid calling into the trace code and
>   used this in FIQ entry from usr path. Modified corresponding exit code
>   to avoid calling into trace code and the scheduler (example code from
>   Russell King).
> 
> * Ensured the default FIQ register state is restored when the default
>   FIQ handler is reinstalled (example code from Russell King).
> 
> * Renamed no_fiq_insn to dfl_fiq_insn to reflect the effect of adopting
>   a default FIQ handler.
> 
> * Re-instated fiq_safe_migration_lock and associated logic in
>   gic_raise_softirq(). gic_raise_softirq() is called by wake_up_klogd()
>   in the console unlock logic.
> 
> v5:
> 
> * Rebased on 3.17-rc4.
> 
> * Removed a spurious line from the final "glue it together" patch
>   that broke the build.
> 
> v4:
> 
> * Replaced push/pop with stmfd/ldmfd respectively (review of Nicolas
>   Pitre).
> 
> * Really fix bad pt_regs pointer generation in __fiq_abt.
> 
> * Remove fiq_safe_migration_lock and associated logic in
>   gic_raise_softirq() (review of Russell King)
> 
> * Restructured to introduce the default FIQ handler first, before the
>   new features (review of Russell King).
> 
> v3:
> 
> * Removed redundant header guards from arch/arm64/include/asm/fiq.h
>   (review of Catalin Marinas).
> 
> * Moved svc_exit_via_fiq macro to entry-header.S (review of Nicolas
>   Pitre).
> 
> v2:
> 
> * Restructured to sit nicely on a similar FYI patchset from Russell
>   King. It now effectively replaces the work in progress final patch
>   with something much more complete.
> 
> * Implemented (and tested) a Thumb-2 implementation of svc_exit_via_fiq
>   (review of Nicolas Pitre)
> 
> * Dropped the GIC group 0 workaround patch. The issue of FIQ interrupts
>   being acknowledged by the IRQ handler does still exist but should be
>   harmless because the IRQ handler will still wind up calling
>   ipi_cpu_backtrace().
> 
> * Removed any dependency on CONFIG_FIQ; all cpu backtrace effectively
>   becomes a platform feature (although the use of non-maskable
>   interrupts to implement it is best effort rather than guaranteed).
> 
> * Better comments highlighting usage of RAZ/WI registers (and parts of
>   registers) in the GIC code.
> 
> Changes *before* v1:
> 
> * This patchset is a hugely cut-down successor to "[PATCH v11 00/19]
>   arm: KGDB NMI/FIQ support". Thanks to Thomas Gleixner for suggesting
>   the new structure. For historic details see:
>         https://lkml.org/lkml/2014/9/2/227
> 
> * Fix bug in __fiq_abt (no longer passes a bad struct pt_regs value).
>   In fixing this we also remove the useless indirection previously
>   found in the fiq_handler macro.
> 
> * Make default fiq handler "always on" by migrating from fiq.c to
>   traps.c and replace do_unexp_fiq with the new handler (review
>   of Russell King).
> 
> * Add arm64 version of fiq.h (review of Russell King)
> 
> * Removed conditional branching and code from irq-gic.c, this is
>   replaced by much simpler code that relies on the GIC specification's
>   heavy use of read-as-zero/write-ignored (review of Russell King)
> 
> 
> Daniel Thompson (4):
>   irqchip: gic: Make gic_raise_softirq() FIQ-safe
>   irqchip: gic: Introduce plumbing for IPI FIQ
>   ARM: add basic support for on-demand backtrace of other CPUs
>   arm: smp: Handle ipi_cpu_backtrace() using FIQ (if available)
> 
>  arch/arm/include/asm/irq.h      |   5 ++
>  arch/arm/include/asm/smp.h      |   3 +
>  arch/arm/kernel/smp.c           |  64 +++++++++++++++
>  arch/arm/kernel/traps.c         |   8 +-
>  drivers/irqchip/irq-gic.c       | 170 +++++++++++++++++++++++++++++++++++++---
>  include/linux/irqchip/arm-gic.h |   8 ++
>  6 files changed, 245 insertions(+), 13 deletions(-)
> 
> --
> 1.9.3
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/