Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Sep 2022 21:12:15 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Yipeng Zou <zouyipeng@huawei.com>
Cc:     <linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        <mingo@redhat.com>, <paul.walmsley@sifive.com>,
        <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,
        <liaochang1@huawei.com>, <chris.zjh@huawei.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 1/2] tracing: hold caller_addr to
 hardirq_{enable,disable}_ip
Message-ID: <20220906211215.0fe6183a@gandalf.local.home>
In-Reply-To: <20220901104515.135162-2-zouyipeng@huawei.com>
References: <20220901104515.135162-1-zouyipeng@huawei.com>
        <20220901104515.135162-2-zouyipeng@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 1 Sep 2022 18:45:14 +0800
Yipeng Zou <zouyipeng@huawei.com> wrote:

> Currently, The arguments passing to lockdep_hardirqs_{on,off} was fixed
> in CALLER_ADDR0.
> The function trace_hardirqs_on_caller should have been intended to use
> caller_addr to represent the address that caller wants to be traced.
> 
> For example, lockdep log in riscv showing the last {enabled,disabled} at
> __trace_hardirqs_{on,off} all the time(if called by):
> [   57.853175] hardirqs last  enabled at (2519): __trace_hardirqs_on+0xc/0x14
> [   57.853848] hardirqs last disabled at (2520): __trace_hardirqs_off+0xc/0x14
> 
> After use trace_hardirqs_xx_caller, we can get more effective information:
> [   53.781428] hardirqs last  enabled at (2595): restore_all+0xe/0x66
> [   53.782185] hardirqs last disabled at (2596): ret_from_exception+0xa/0x10

I'm going to mark this as stable and send it in my next push to Linus.

I'll also add:

Fixes: c3bc8fd637a96 ("tracing: Centralize preemptirq tracepoints and unify their usage")

The code was copied from functions that were originally called directly,
but now that they are called indirectly, CALLER_ADDR0 is not the right
thing to use.

Thanks!

-- Steve


> 
> Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
> ---
>  kernel/trace/trace_preemptirq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
> index 95b58bd757ce..1e130da1b742 100644
> --- a/kernel/trace/trace_preemptirq.c
> +++ b/kernel/trace/trace_preemptirq.c
> @@ -95,14 +95,14 @@ __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
>  	}
>  
>  	lockdep_hardirqs_on_prepare();
> -	lockdep_hardirqs_on(CALLER_ADDR0);
> +	lockdep_hardirqs_on(caller_addr);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_on_caller);
>  NOKPROBE_SYMBOL(trace_hardirqs_on_caller);
>  
>  __visible void trace_hardirqs_off_caller(unsigned long caller_addr)
>  {
> -	lockdep_hardirqs_off(CALLER_ADDR0);
> +	lockdep_hardirqs_off(caller_addr);
>  
>  	if (!this_cpu_read(tracing_irq_cpu)) {
>  		this_cpu_write(tracing_irq_cpu, 1);