Hi Zenghui,
On 29/03/2019 13:23, Zenghui Yu wrote:
> Enable pseudo NMI together with function_graph tracer, will lead
> the system to a hang. This is easy to reproduce,
>
> 1) Set "irqchip.gicv3_pseudo_nmi=1" on the kernel command line
> 2) echo function_graph > /sys/kernel/debug/tracing/current_tracer
>
> This patch (RFC) set gic_handle_irq() as notrace and it seems works
> fine now. But I have no idea about what the issue is exactly, and
> you can regard this patch as a report then :)
>
> Can someone give a look at it and provide some explanations ?
>
> Thanks!
>
> Cc: Julien Thierry <julien.thie...@arm.com>
> Cc: Steven Rostedt <rost...@goodmis.org>
> Signed-off-by: Zenghui Yu <yuzeng...@huawei.com>
> ---
> drivers/irqchip/irq-gic-v3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 15e55d3..8d0c25f 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -487,7 +487,7 @@ static inline void gic_handle_nmi(u32 irqnr, struct
> pt_regs *regs)
> gic_deactivate_unhandled(irqnr);
> }
>
> -static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs
> *regs)
> +static asmlinkage notrace void __exception_irq_entry gic_handle_irq(struct
> pt_regs *regs)
> {
> u32 irqnr;
>
>
That's interesting. Do you have any out of tree patch that actually
makes use of the pseudo-NMI feature? Without those patches, the
behaviour should stay unchanged.
On the other hand, if you can generate pseudo-NMIs, you could end-up
tracing gic_handle_irq whilst being inside the tracing code with
interrupts being notionally disabled (and that could be pretty bad).
So, patches or no patches?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
