linux-kernel - Re: [PATCH 1/2] tracing: hold caller_addr to hardirq_{enable,disable}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Sep 2022 21:12:15 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Yipeng Zou <zouyipeng@...wei.com>
Cc:     <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <mingo@...hat.com>, <paul.walmsley@...ive.com>,
        <palmer@...belt.com>, <aou@...s.berkeley.edu>,
        <liaochang1@...wei.com>, <chris.zjh@...wei.com>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH 1/2] tracing: hold caller_addr to
 hardirq_{enable,disable}_ip

On Thu, 1 Sep 2022 18:45:14 +0800
Yipeng Zou <zouyipeng@...wei.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@...wei.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);