linux-kernel - Re: [PATCH v5 1/2] function_graph: Support recording and printing the return value of function

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: <ZBnqAYO7rdk4Qikq@shell.armlinux.org.uk>
Date:   Tue, 21 Mar 2023 17:31:45 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Donglin Peng <pengdonglin@...gfor.com.cn>
Cc:     mhiramat@...nel.org, rostedt@...dmis.org, mark.rutland@....com,
        will@...nel.org, catalin.marinas@....com, palmer@...belt.com,
        paul.walmsley@...ive.com, tglx@...utronix.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, mingo@...hat.com,
        xiehuan09@...il.com, dinghui@...gfor.com.cn,
        huangcun@...gfor.com.cn, dolinux.peng@...il.com,
        linux-trace-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/2] function_graph: Support recording and printing
 the return value of function

On Mon, Mar 20, 2023 at 06:16:49AM -0700, Donglin Peng wrote:
> diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S
> index 3e7bcaca5e07..ba1986e27af8 100644
> --- a/arch/arm/kernel/entry-ftrace.S
> +++ b/arch/arm/kernel/entry-ftrace.S
> @@ -258,7 +258,15 @@ ENDPROC(ftrace_graph_regs_caller)
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  ENTRY(return_to_handler)
>  	stmdb	sp!, {r0-r3}
> +#ifdef CONFIG_FUNCTION_GRAPH_RETVAL
> +	/*
> +	 * Pass both the function return values in the register r0 and r1
> +	 * to ftrace_return_to_handler
> +	 */
> +	add	r2, sp, #16		@ sp at exit of instrumented routine
> +#else
>  	add	r0, sp, #16		@ sp at exit of instrumented routine
> +#endif
>  	bl	ftrace_return_to_handler
...
> -unsigned long ftrace_return_to_handler(unsigned long frame_pointer)
> +static unsigned long __ftrace_return_to_handler(unsigned long retval_1st,
> +			unsigned long retval_2nd, unsigned long frame_pointer)
...
> +#ifdef CONFIG_FUNCTION_GRAPH_RETVAL
> +unsigned long ftrace_return_to_handler(unsigned long retval_1st,
> +			unsigned long retval_2nd, unsigned long frame_pointer)
> +{
> +	return __ftrace_return_to_handler(retval_1st, retval_2nd, frame_pointer);
> +}
> +#else
> +unsigned long ftrace_return_to_handler(unsigned long frame_pointer)
> +{
> +	return __ftrace_return_to_handler(0, 0, frame_pointer);
> +}
> +#endif
> +

Hi,

To echo Mark's criticism, I also don't like this. I feel it would be
better if ftrace_return_to_handler() always took the same arguments
irrespective of the setting of CONFIG_FUNCTION_GRAPH_RETVAL.

On 32-bit ARM, we have to stack r0-r3 anyway to prevent the call to
ftrace_return_to_handler() corrupting the return value, and these
are the registers we need. So we might as well pass a pointer to
these stacked registers. Whether that's acceptable on other
architectures, I couldn't say.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!