linux-kernel - Re: [PATCH] kernel/extable.c: mark core_kernel

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]

Message-ID: <20170622181050.220c23a3@gandalf.local.home>
Date:   Thu, 22 Jun 2017 18:10:50 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Marcin Nowakowski <marcin.nowakowski@...tec.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Thomas Meyer <thomas@...3r.de>, Ingo Molnar <mingo@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>, <linux-mips@...ux-mips.org>
Subject: Re: [PATCH] kernel/extable.c: mark core_kernel_text notrace

On Wed, 21 Jun 2017 09:03:26 +0200
Marcin Nowakowski <marcin.nowakowski@...tec.com> wrote:

> core_kernel_text is used by MIPS in its function graph trace processing,
> so having this method traced leads to an infinite set of recursive calls
> such as:
> 
> [    2.972075] Call Trace:
> [    2.972111]
> [    2.976731] [<80506584>] ftrace_return_to_handler+0x50/0x128
> [    2.983379] [<8045478c>] core_kernel_text+0x10/0x1b8
> [    2.989146] [<804119b8>] prepare_ftrace_return+0x6c/0x114
> [    2.995402] [<80411b2c>] ftrace_graph_caller+0x20/0x44
> [    3.001362] [<80411b60>] return_to_handler+0x10/0x30
> [    3.007159] [<80411b50>] return_to_handler+0x0/0x30
> [    3.012827] [<80411b50>] return_to_handler+0x0/0x30
> [    3.018621] [<804e589c>] ftrace_ops_no_ops+0x114/0x1bc
> [    3.024602] [<8045478c>] core_kernel_text+0x10/0x1b8
> [    3.030377] [<8045478c>] core_kernel_text+0x10/0x1b8
> [    3.036140] [<8045478c>] core_kernel_text+0x10/0x1b8
> [    3.041915] [<804e589c>] ftrace_ops_no_ops+0x114/0x1bc
> [    3.047923] [<8045478c>] core_kernel_text+0x10/0x1b8
> [    3.053682] [<804119b8>] prepare_ftrace_return+0x6c/0x114
> [    3.059938] [<80411b2c>] ftrace_graph_caller+0x20/0x44
> (...)
> 
> Mark the function notrace to avoid it being traced.
> 
> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@...tec.com>
> ---
>  kernel/extable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/extable.c b/kernel/extable.c
> index 2676d7f..4efaf26 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -70,7 +70,7 @@ static inline int init_kernel_text(unsigned long addr)
>  	return 0;
>  }
>  
> -int core_kernel_text(unsigned long addr)
> +int notrace core_kernel_text(unsigned long addr)

Is mips the only one with this issue. I hate adding notrace to general
functions if it is only an issue with a single arch.

Can we add a: mips_notrace? where we have:

#ifdef CONFIG_MIPS
# define mips_notrace notrace
#else 
# define mips_notrace
#endif

??

-- Steve


>  {
>  	if (addr >= (unsigned long)_stext &&
>  	    addr < (unsigned long)_etext)