Re: [PATCH v15 09/19] tracing: Add ftrace_fill_perf_regs() for perf event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 15, 2024 at 06:11:14PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> 
> Add ftrace_fill_perf_regs() which should be compatible with the
> perf_fetch_caller_regs(). In other words, the pt_regs returned from the
> ftrace_fill_perf_regs() must satisfy 'user_mode(regs) == false' and can be
> used for stack tracing.
> 
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
...
>  arch/s390/include/asm/ftrace.h    |    5 +++++
...
> diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
> index 9cdd48a46bf7..0d9f6df21f81 100644
> --- a/arch/s390/include/asm/ftrace.h
> +++ b/arch/s390/include/asm/ftrace.h
> @@ -84,6 +84,11 @@ ftrace_regs_get_frame_pointer(struct ftrace_regs *fregs)
>  	return sp[0];	/* return backchain */
>  }
>  
> +#define arch_ftrace_fill_perf_regs(fregs, _regs)	 do {		\
> +		(_regs)->psw.addr = (fregs)->regs.psw.addr;		\
> +		(_regs)->gprs[15] = (fregs)->regs.gprs[15];		\
> +	} while (0)

After reading your commit description and looking at the code I think the
s390 implementation of perf_arch_fetch_caller_regs() is at least
suboptimal: it is not possible to tell if an address belongs to user or
kernel space by looking only at the address (psw.addr); this also requires
to look at psw.mask. It _looks_ like all current callers of
perf_arch_fetch_caller_regs() initialize the passed in pt_regs to zero,
which of course also sets psw.mask to zero, and therefore
user_mode(regs) == false is satisfied.

However I'd rather make that explicit and don't want to rely on
callers. Therefore the above arch_ftrace_fill_perf_regs() should
set the mask to zero

		(_regs)->psw.mask = 0;

I will change perf_arch_fetch_caller_regs() accordingly.




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux