All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Donglin Peng <pengdonglin@sangfor.com.cn>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, linux@armlinux.org.uk,
	will@kernel.org, catalin.marinas@arm.com,
	rmk+kernel@armlinux.org.uk, palmer@dabbelt.com,
	paul.walmsley@sifive.com, aou@eecs.berkeley.edu,
	tglx@linutronix.de, dave.hansen@linux.intel.com, x86@kernel.org,
	bp@alien8.de, hpa@zytor.com, chenhuacai@kernel.org,
	zhangqing@loongson.cn, kernel@xen0n.name, mingo@redhat.com,
	peterz@infradead.org, xiehuan09@gmail.com,
	dinghui@sangfor.com.cn, huangcun@sangfor.com.cn,
	dolinux.peng@gmail.com, linux-trace-kernel@vger.kernel.org,
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 2/8] tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex
Date: Mon, 3 Apr 2023 09:30:15 +0100	[thread overview]
Message-ID: <ZCqOl1TCHGhbf0hf@FVFF77S0Q05N> (raw)
In-Reply-To: <a3dcdd61b3ac07eefabc1b11fc18e9fae23d8cbe.1680265828.git.pengdonglin@sangfor.com.cn>

On Fri, Mar 31, 2023 at 05:47:38AM -0700, Donglin Peng wrote:
> Add documentation for the two newly introduced options for the
> function_graph tracer. The funcgraph-retval option is used to
> control whether or not to display the return value, while the
> funcgraph-retval-hex option is used to control the display
> format of the return value.
> 
> Signed-off-by: Donglin Peng <pengdonglin@sangfor.com.cn>
> ---
> v9:
>  - Update limitation description
> 
> v7:
>  - Rename trace option 'graph_retval_hex' to 'funcgraph-retval-hex'
>  - Update documentation description
> 
> v6:
>  - Modify the limitations for funcgraph-retval
>  - Optimize the English expression
> 
> v5:
>  - Describe the limitations of funcgraph-retval
> ---
>  Documentation/trace/ftrace.rst | 74 ++++++++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index b927fb2b94dc..f572ae419219 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -1328,6 +1328,19 @@ Options for function_graph tracer:
>  	only a closing curly bracket "}" is displayed for
>  	the return of a function.
>  
> +  funcgraph-retval
> +	When set, the return value of each traced function
> +	will be printed after an equal sign "=". By default
> +	this is off.
> +
> +  funcgraph-retval-hex
> +	When set, the return value will always be printed
> +	in hexadecimal format. If the option is not set and
> +	the return value is an error code, it will be printed
> +	in signed decimal format; otherwise it will also be
> +	printed in hexadecimal format. By default, this option
> +	is off.
> +
>    sleep-time
>  	When running function graph tracer, to include
>  	the time a task schedules out in its function.
> @@ -2673,6 +2686,67 @@ It is default disabled.
>      0)   1.757 us    |        } /* kmem_cache_free() */
>      0)   2.861 us    |      } /* putname() */
>  
> +The return value of each traced function can be displayed after
> +an equal sign "=". When encountering system call failures, it
> +can be verfy helpful to quickly locate the function that first
> +returns an error code.
> +
> +	- hide: echo nofuncgraph-retval > trace_options
> +	- show: echo funcgraph-retval > trace_options
> +
> +  Example with funcgraph-retval::
> +
> +    1)               |    cgroup_migrate() {
> +    1)   0.651 us    |      cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |      cgroup_migrate_execute() {
> +    1)               |        cpu_cgroup_can_attach() {
> +    1)               |          cgroup_taskset_first() {
> +    1)   0.732 us    |            cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |          } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |          sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |        } /* cpu_cgroup_can_attach = -22 */
> +    1)   4.369 us    |      } /* cgroup_migrate_execute = -22 */
> +    1)   7.143 us    |    } /* cgroup_migrate = -22 */
> +
> +The above example shows that the function cpu_cgroup_can_attach
> +returned the error code -22 firstly, then we can read the code
> +of this function to get the root cause.
> +
> +When the option funcgraph-retval-hex is not set, the return value can
> +be displayed in a smart way. Specifically, if it is an error code,
> +it will be printed in signed decimal format, otherwise it will
> +printed in hexadecimal format.
> +
> +	- smart: echo nofuncgraph-retval-hex > trace_options
> +	- hexadecimal always: echo funcgraph-retval-hex > trace_options
> +
> +  Example with funcgraph-retval-hex::
> +
> +    1)               |      cgroup_migrate() {
> +    1)   0.651 us    |        cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |        cgroup_migrate_execute() {
> +    1)               |          cpu_cgroup_can_attach() {
> +    1)               |            cgroup_taskset_first() {
> +    1)   0.732 us    |              cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |            } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |            sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |          } /* cpu_cgroup_can_attach = 0xffffffea */
> +    1)   4.369 us    |        } /* cgroup_migrate_execute = 0xffffffea */
> +    1)   7.143 us    |      } /* cgroup_migrate = 0xffffffea */
> +
> +At present, there are some limitations when using the funcgraph-retval
> +option, and these limitations will be eliminated in the future:
> +
> +- Even if the function return type is void, a return value will still
> +  be printed, and you can just ignore it.
> +
> +- Even if return values are stored in multiple registers, only the
> +  value contained in the first register will be recorded and printed.
> +  To illustrate, in the x86 architecture, eax and edx are used to store
> +  a 64-bit return value, with the lower 32 bits saved in eax and the
> +  upper 32 bits saved in edx. However, only the value stored in eax
> +  will be recorded and printed.

With some procedure call standards (e.g. arm64's AAPCS64), when a type is
smaller than a GPR it's up to the consumer to perform the narrowing, and the
upport bits may contain UNKNOWN values. For example, with a u8 in a 64-bit GPR,
bits [3:8] may contain arbitrary values.

It's probably worth noting that this means *some* manual processing will always
be necessary for such cases.

That's mostly visible around where largelr types get truncated (whether
explciitly or implicitly), e.g.

	u8 narrow_to_u8(u64 val)
	{
		// implicitly truncated
		return val;
	}

... could be compiled to:

	narrow_to_u8:
		< ... ftrace instrumentation ... >
		RET

... and so:
	
	narrow_to_u8(0x123456789abcdef);

... might be recorded as returning 0x123456789abcdef rather than 0xef.


That can happen in surprising ways, e.g.

	int error_if_not_4g_aligned(u64 val)
	{
		if (val & GENMASK(63, 32))
			return -EINVAL;

		return 0;
	}

... could be compiled to:

	error_if_not_4g_aligned:
		CBNZ	w0, .Lnot_aligned
		RET				// bits [31:0] are zero, bits
						// [63:32] are UNKNOWN
	.Lnot_aligned:
		MOV	x0, #-EINVAL
		RET

.... and so:

	error_if_not_4g_aligned(SZ_8G)

... could return with bits [63:32] non-zero

Thanks,
Mark.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Donglin Peng <pengdonglin@sangfor.com.cn>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, linux@armlinux.org.uk,
	will@kernel.org, catalin.marinas@arm.com,
	rmk+kernel@armlinux.org.uk, palmer@dabbelt.com,
	paul.walmsley@sifive.com, aou@eecs.berkeley.edu,
	tglx@linutronix.de, dave.hansen@linux.intel.com, x86@kernel.org,
	bp@alien8.de, hpa@zytor.com, chenhuacai@kernel.org,
	zhangqing@loongson.cn, kernel@xen0n.name, mingo@redhat.com,
	peterz@infradead.org, xiehuan09@gmail.com,
	dinghui@sangfor.com.cn, huangcun@sangfor.com.cn,
	dolinux.peng@gmail.com, linux-trace-kernel@vger.kernel.org,
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 2/8] tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex
Date: Mon, 3 Apr 2023 09:30:15 +0100	[thread overview]
Message-ID: <ZCqOl1TCHGhbf0hf@FVFF77S0Q05N> (raw)
In-Reply-To: <a3dcdd61b3ac07eefabc1b11fc18e9fae23d8cbe.1680265828.git.pengdonglin@sangfor.com.cn>

On Fri, Mar 31, 2023 at 05:47:38AM -0700, Donglin Peng wrote:
> Add documentation for the two newly introduced options for the
> function_graph tracer. The funcgraph-retval option is used to
> control whether or not to display the return value, while the
> funcgraph-retval-hex option is used to control the display
> format of the return value.
> 
> Signed-off-by: Donglin Peng <pengdonglin@sangfor.com.cn>
> ---
> v9:
>  - Update limitation description
> 
> v7:
>  - Rename trace option 'graph_retval_hex' to 'funcgraph-retval-hex'
>  - Update documentation description
> 
> v6:
>  - Modify the limitations for funcgraph-retval
>  - Optimize the English expression
> 
> v5:
>  - Describe the limitations of funcgraph-retval
> ---
>  Documentation/trace/ftrace.rst | 74 ++++++++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index b927fb2b94dc..f572ae419219 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -1328,6 +1328,19 @@ Options for function_graph tracer:
>  	only a closing curly bracket "}" is displayed for
>  	the return of a function.
>  
> +  funcgraph-retval
> +	When set, the return value of each traced function
> +	will be printed after an equal sign "=". By default
> +	this is off.
> +
> +  funcgraph-retval-hex
> +	When set, the return value will always be printed
> +	in hexadecimal format. If the option is not set and
> +	the return value is an error code, it will be printed
> +	in signed decimal format; otherwise it will also be
> +	printed in hexadecimal format. By default, this option
> +	is off.
> +
>    sleep-time
>  	When running function graph tracer, to include
>  	the time a task schedules out in its function.
> @@ -2673,6 +2686,67 @@ It is default disabled.
>      0)   1.757 us    |        } /* kmem_cache_free() */
>      0)   2.861 us    |      } /* putname() */
>  
> +The return value of each traced function can be displayed after
> +an equal sign "=". When encountering system call failures, it
> +can be verfy helpful to quickly locate the function that first
> +returns an error code.
> +
> +	- hide: echo nofuncgraph-retval > trace_options
> +	- show: echo funcgraph-retval > trace_options
> +
> +  Example with funcgraph-retval::
> +
> +    1)               |    cgroup_migrate() {
> +    1)   0.651 us    |      cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |      cgroup_migrate_execute() {
> +    1)               |        cpu_cgroup_can_attach() {
> +    1)               |          cgroup_taskset_first() {
> +    1)   0.732 us    |            cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |          } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |          sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |        } /* cpu_cgroup_can_attach = -22 */
> +    1)   4.369 us    |      } /* cgroup_migrate_execute = -22 */
> +    1)   7.143 us    |    } /* cgroup_migrate = -22 */
> +
> +The above example shows that the function cpu_cgroup_can_attach
> +returned the error code -22 firstly, then we can read the code
> +of this function to get the root cause.
> +
> +When the option funcgraph-retval-hex is not set, the return value can
> +be displayed in a smart way. Specifically, if it is an error code,
> +it will be printed in signed decimal format, otherwise it will
> +printed in hexadecimal format.
> +
> +	- smart: echo nofuncgraph-retval-hex > trace_options
> +	- hexadecimal always: echo funcgraph-retval-hex > trace_options
> +
> +  Example with funcgraph-retval-hex::
> +
> +    1)               |      cgroup_migrate() {
> +    1)   0.651 us    |        cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |        cgroup_migrate_execute() {
> +    1)               |          cpu_cgroup_can_attach() {
> +    1)               |            cgroup_taskset_first() {
> +    1)   0.732 us    |              cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |            } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |            sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |          } /* cpu_cgroup_can_attach = 0xffffffea */
> +    1)   4.369 us    |        } /* cgroup_migrate_execute = 0xffffffea */
> +    1)   7.143 us    |      } /* cgroup_migrate = 0xffffffea */
> +
> +At present, there are some limitations when using the funcgraph-retval
> +option, and these limitations will be eliminated in the future:
> +
> +- Even if the function return type is void, a return value will still
> +  be printed, and you can just ignore it.
> +
> +- Even if return values are stored in multiple registers, only the
> +  value contained in the first register will be recorded and printed.
> +  To illustrate, in the x86 architecture, eax and edx are used to store
> +  a 64-bit return value, with the lower 32 bits saved in eax and the
> +  upper 32 bits saved in edx. However, only the value stored in eax
> +  will be recorded and printed.

With some procedure call standards (e.g. arm64's AAPCS64), when a type is
smaller than a GPR it's up to the consumer to perform the narrowing, and the
upport bits may contain UNKNOWN values. For example, with a u8 in a 64-bit GPR,
bits [3:8] may contain arbitrary values.

It's probably worth noting that this means *some* manual processing will always
be necessary for such cases.

That's mostly visible around where largelr types get truncated (whether
explciitly or implicitly), e.g.

	u8 narrow_to_u8(u64 val)
	{
		// implicitly truncated
		return val;
	}

... could be compiled to:

	narrow_to_u8:
		< ... ftrace instrumentation ... >
		RET

... and so:
	
	narrow_to_u8(0x123456789abcdef);

... might be recorded as returning 0x123456789abcdef rather than 0xef.


That can happen in surprising ways, e.g.

	int error_if_not_4g_aligned(u64 val)
	{
		if (val & GENMASK(63, 32))
			return -EINVAL;

		return 0;
	}

... could be compiled to:

	error_if_not_4g_aligned:
		CBNZ	w0, .Lnot_aligned
		RET				// bits [31:0] are zero, bits
						// [63:32] are UNKNOWN
	.Lnot_aligned:
		MOV	x0, #-EINVAL
		RET

.... and so:

	error_if_not_4g_aligned(SZ_8G)

... could return with bits [63:32] non-zero

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Donglin Peng <pengdonglin@sangfor.com.cn>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, linux@armlinux.org.uk,
	will@kernel.org, catalin.marinas@arm.com,
	rmk+kernel@armlinux.org.uk, palmer@dabbelt.com,
	paul.walmsley@sifive.com, aou@eecs.berkeley.edu,
	tglx@linutronix.de, dave.hansen@linux.intel.com, x86@kernel.org,
	bp@alien8.de, hpa@zytor.com, chenhuacai@kernel.org,
	zhangqing@loongson.cn, kernel@xen0n.name, mingo@redhat.com,
	peterz@infradead.org, xiehuan09@gmail.com,
	dinghui@sangfor.com.cn, huangcun@sangfor.com.cn,
	dolinux.peng@gmail.com, linux-trace-kernel@vger.kernel.org,
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 2/8] tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex
Date: Mon, 3 Apr 2023 09:30:15 +0100	[thread overview]
Message-ID: <ZCqOl1TCHGhbf0hf@FVFF77S0Q05N> (raw)
In-Reply-To: <a3dcdd61b3ac07eefabc1b11fc18e9fae23d8cbe.1680265828.git.pengdonglin@sangfor.com.cn>

On Fri, Mar 31, 2023 at 05:47:38AM -0700, Donglin Peng wrote:
> Add documentation for the two newly introduced options for the
> function_graph tracer. The funcgraph-retval option is used to
> control whether or not to display the return value, while the
> funcgraph-retval-hex option is used to control the display
> format of the return value.
> 
> Signed-off-by: Donglin Peng <pengdonglin@sangfor.com.cn>
> ---
> v9:
>  - Update limitation description
> 
> v7:
>  - Rename trace option 'graph_retval_hex' to 'funcgraph-retval-hex'
>  - Update documentation description
> 
> v6:
>  - Modify the limitations for funcgraph-retval
>  - Optimize the English expression
> 
> v5:
>  - Describe the limitations of funcgraph-retval
> ---
>  Documentation/trace/ftrace.rst | 74 ++++++++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index b927fb2b94dc..f572ae419219 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -1328,6 +1328,19 @@ Options for function_graph tracer:
>  	only a closing curly bracket "}" is displayed for
>  	the return of a function.
>  
> +  funcgraph-retval
> +	When set, the return value of each traced function
> +	will be printed after an equal sign "=". By default
> +	this is off.
> +
> +  funcgraph-retval-hex
> +	When set, the return value will always be printed
> +	in hexadecimal format. If the option is not set and
> +	the return value is an error code, it will be printed
> +	in signed decimal format; otherwise it will also be
> +	printed in hexadecimal format. By default, this option
> +	is off.
> +
>    sleep-time
>  	When running function graph tracer, to include
>  	the time a task schedules out in its function.
> @@ -2673,6 +2686,67 @@ It is default disabled.
>      0)   1.757 us    |        } /* kmem_cache_free() */
>      0)   2.861 us    |      } /* putname() */
>  
> +The return value of each traced function can be displayed after
> +an equal sign "=". When encountering system call failures, it
> +can be verfy helpful to quickly locate the function that first
> +returns an error code.
> +
> +	- hide: echo nofuncgraph-retval > trace_options
> +	- show: echo funcgraph-retval > trace_options
> +
> +  Example with funcgraph-retval::
> +
> +    1)               |    cgroup_migrate() {
> +    1)   0.651 us    |      cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |      cgroup_migrate_execute() {
> +    1)               |        cpu_cgroup_can_attach() {
> +    1)               |          cgroup_taskset_first() {
> +    1)   0.732 us    |            cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |          } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |          sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |        } /* cpu_cgroup_can_attach = -22 */
> +    1)   4.369 us    |      } /* cgroup_migrate_execute = -22 */
> +    1)   7.143 us    |    } /* cgroup_migrate = -22 */
> +
> +The above example shows that the function cpu_cgroup_can_attach
> +returned the error code -22 firstly, then we can read the code
> +of this function to get the root cause.
> +
> +When the option funcgraph-retval-hex is not set, the return value can
> +be displayed in a smart way. Specifically, if it is an error code,
> +it will be printed in signed decimal format, otherwise it will
> +printed in hexadecimal format.
> +
> +	- smart: echo nofuncgraph-retval-hex > trace_options
> +	- hexadecimal always: echo funcgraph-retval-hex > trace_options
> +
> +  Example with funcgraph-retval-hex::
> +
> +    1)               |      cgroup_migrate() {
> +    1)   0.651 us    |        cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
> +    1)               |        cgroup_migrate_execute() {
> +    1)               |          cpu_cgroup_can_attach() {
> +    1)               |            cgroup_taskset_first() {
> +    1)   0.732 us    |              cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
> +    1)   1.232 us    |            } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
> +    1)   0.380 us    |            sched_rt_can_attach(); /* = 0x0 */
> +    1)   2.335 us    |          } /* cpu_cgroup_can_attach = 0xffffffea */
> +    1)   4.369 us    |        } /* cgroup_migrate_execute = 0xffffffea */
> +    1)   7.143 us    |      } /* cgroup_migrate = 0xffffffea */
> +
> +At present, there are some limitations when using the funcgraph-retval
> +option, and these limitations will be eliminated in the future:
> +
> +- Even if the function return type is void, a return value will still
> +  be printed, and you can just ignore it.
> +
> +- Even if return values are stored in multiple registers, only the
> +  value contained in the first register will be recorded and printed.
> +  To illustrate, in the x86 architecture, eax and edx are used to store
> +  a 64-bit return value, with the lower 32 bits saved in eax and the
> +  upper 32 bits saved in edx. However, only the value stored in eax
> +  will be recorded and printed.

With some procedure call standards (e.g. arm64's AAPCS64), when a type is
smaller than a GPR it's up to the consumer to perform the narrowing, and the
upport bits may contain UNKNOWN values. For example, with a u8 in a 64-bit GPR,
bits [3:8] may contain arbitrary values.

It's probably worth noting that this means *some* manual processing will always
be necessary for such cases.

That's mostly visible around where largelr types get truncated (whether
explciitly or implicitly), e.g.

	u8 narrow_to_u8(u64 val)
	{
		// implicitly truncated
		return val;
	}

... could be compiled to:

	narrow_to_u8:
		< ... ftrace instrumentation ... >
		RET

... and so:
	
	narrow_to_u8(0x123456789abcdef);

... might be recorded as returning 0x123456789abcdef rather than 0xef.


That can happen in surprising ways, e.g.

	int error_if_not_4g_aligned(u64 val)
	{
		if (val & GENMASK(63, 32))
			return -EINVAL;

		return 0;
	}

... could be compiled to:

	error_if_not_4g_aligned:
		CBNZ	w0, .Lnot_aligned
		RET				// bits [31:0] are zero, bits
						// [63:32] are UNKNOWN
	.Lnot_aligned:
		MOV	x0, #-EINVAL
		RET

.... and so:

	error_if_not_4g_aligned(SZ_8G)

... could return with bits [63:32] non-zero

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-04-03  8:30 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 12:47 [PATCH v10 0/8] function_graph: Support recording and printing the return value of function Donglin Peng
2023-03-31 12:47 ` Donglin Peng
2023-03-31 12:47 ` Donglin Peng
2023-03-31 12:47 ` [PATCH v10 1/8] " Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47 ` [PATCH v10 2/8] tracing: Add documentation for funcgraph-retval and funcgraph-retval-hex Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-04-01 22:17   ` Masami Hiramatsu
2023-04-01 22:17     ` Masami Hiramatsu
2023-04-01 22:17     ` Masami Hiramatsu
2023-04-03  8:30   ` Mark Rutland [this message]
2023-04-03  8:30     ` Mark Rutland
2023-04-03  8:30     ` Mark Rutland
2023-04-04 12:02     ` Donglin Peng
2023-04-04 12:02       ` Donglin Peng
2023-04-04 12:02       ` Donglin Peng
2023-04-04 12:52       ` Mark Rutland
2023-04-04 12:52         ` Mark Rutland
2023-04-04 12:52         ` Mark Rutland
2023-03-31 12:47 ` [PATCH v10 3/8] ARM: ftrace: Enable HAVE_FUNCTION_GRAPH_RETVAL Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47 ` [PATCH v10 4/8] arm64: " Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-04-03  8:13   ` Mark Rutland
2023-04-03  8:13     ` Mark Rutland
2023-04-03  8:13     ` Mark Rutland
2023-03-31 12:47 ` [PATCH v10 5/8] riscv: " Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47 ` [PATCH v10 6/8] x86/ftrace: " Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47 ` [PATCH v10 7/8] LoongArch: ftrace: " Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-04-03  0:54   ` Huacai Chen
2023-04-03  0:54     ` Huacai Chen
2023-04-03  0:54     ` Huacai Chen
2023-03-31 12:47 ` [PATCH v10 8/8] selftests/ftrace: Add funcgraph-retval test case Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-03-31 12:47   ` Donglin Peng
2023-04-01 22:04   ` Masami Hiramatsu
2023-04-01 22:04     ` Masami Hiramatsu
2023-04-01 22:04     ` Masami Hiramatsu
2023-04-03  2:33     ` Donglin Peng
2023-04-03  2:33       ` Donglin Peng
2023-04-03  2:33       ` Donglin Peng
2023-04-03  5:01       ` Donglin Peng
2023-04-03  5:01         ` Donglin Peng
2023-04-03  5:01         ` Donglin Peng
2023-04-06 10:35         ` Donglin Peng
2023-04-06 10:35           ` Donglin Peng
2023-04-06 10:35           ` Donglin Peng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZCqOl1TCHGhbf0hf@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dinghui@sangfor.com.cn \
    --cc=dolinux.peng@gmail.com \
    --cc=hpa@zytor.com \
    --cc=huangcun@sangfor.com.cn \
    --cc=kernel@xen0n.name \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=loongarch@lists.linux.dev \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pengdonglin@sangfor.com.cn \
    --cc=peterz@infradead.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xiehuan09@gmail.com \
    --cc=zhangqing@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.