All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: broonie@kernel.org, jpoimboe@redhat.com, ardb@kernel.org,
	nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com,
	catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org,
	pasha.tatashin@soleen.com, jthierry@redhat.com,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v6 1/3] arm64: Improve the unwinder return value
Date: Thu, 29 Jul 2021 08:54:58 -0500	[thread overview]
Message-ID: <52686cb6-573c-03ca-06c2-67ae07c91243@linux.microsoft.com> (raw)
In-Reply-To: <20210728165635.GA47345@C02TD0UTHF1T.local>

Thanks for the review. Responses inline...

On 7/28/21 11:56 AM, Mark Rutland wrote:
> On Wed, Jun 30, 2021 at 05:33:54PM -0500, madvenka@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>>
>> Currently, the unwinder returns a tri-state return value:
>>
>> 	0		means "continue with the unwind"
>> 	-ENOENT		means "successful termination of the stack trace"
>> 	-EINVAL		means "fatal error, abort the stack trace"
>>
>> This is confusing. To fix this, define an enumeration of different return
>> codes to make it clear. Handle the return codes in all of the unwind
>> consumers.
> 
> I agree the tri-state is confusing, and I also generally agree that
> enums are preferabel to a set of error codes. However, I don't think
> this is quite the right abstraction; more on that below.
> 

OK.

>>
>> Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
>> ---
>>  arch/arm64/include/asm/stacktrace.h | 14 ++++++--
>>  arch/arm64/kernel/perf_callchain.c  |  5 ++-
>>  arch/arm64/kernel/process.c         |  8 +++--
>>  arch/arm64/kernel/return_address.c  | 10 ++++--
>>  arch/arm64/kernel/stacktrace.c      | 53 ++++++++++++++++-------------
>>  arch/arm64/kernel/time.c            |  9 +++--
>>  6 files changed, 64 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
>> index eb29b1fe8255..6fcd58553fb1 100644
>> --- a/arch/arm64/include/asm/stacktrace.h
>> +++ b/arch/arm64/include/asm/stacktrace.h
>> @@ -30,6 +30,12 @@ struct stack_info {
>>  	enum stack_type type;
>>  };
>>  
>> +enum unwind_rc {
>> +	UNWIND_CONTINUE,		/* No errors encountered */
>> +	UNWIND_ABORT,			/* Fatal errors encountered */
>> +	UNWIND_FINISH,			/* End of stack reached successfully */
>> +};
> 
> Generally, there are a bunch of properties we might need to check for an
> unwind step relating to reliabiltiy (e.g. as you add
> UNWIND_CONTINUE_WITH_RISK in the next patch), and I'd prefer that we
> check those properties on the struct stackframe, and simplify
> unwind_frame() to return a bool.
> 
> Something akin to the x86 unwinders, where the main loop looks like:
> 
> for (unwind_start(&state, ...);
>      !unwind_done(&state) && !unwind_error(&state);
>      unwind_next_frame(&state) {
> 	...
> }
> 
> That way we don't have to grow the enum to handle every variation that
> we can think of, and it's simple enough for users to check the
> properties with the helpers.
> 

I can do that.

>> +
>>  /*
>>   * A snapshot of a frame record or fp/lr register values, along with some
>>   * accounting information necessary for robust unwinding.
>> @@ -61,7 +67,8 @@ struct stackframe {
>>  #endif
>>  };
>>  
>> -extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
>> +extern enum unwind_rc unwind_frame(struct task_struct *tsk,
>> +				   struct stackframe *frame);
>>  extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
>>  			    bool (*fn)(void *, unsigned long), void *data);
>>  extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> @@ -148,8 +155,8 @@ static inline bool on_accessible_stack(const struct task_struct *tsk,
>>  	return false;
>>  }
>>  
>> -static inline void start_backtrace(struct stackframe *frame,
>> -				   unsigned long fp, unsigned long pc)
>> +static inline enum unwind_rc start_backtrace(struct stackframe *frame,
>> +					     unsigned long fp, unsigned long pc)
>>  {
>>  	frame->fp = fp;
>>  	frame->pc = pc;
>> @@ -169,6 +176,7 @@ static inline void start_backtrace(struct stackframe *frame,
>>  	bitmap_zero(frame->stacks_done, __NR_STACK_TYPES);
>>  	frame->prev_fp = 0;
>>  	frame->prev_type = STACK_TYPE_UNKNOWN;
>> +	return UNWIND_CONTINUE;
>>  }
>>  
>>  #endif	/* __ASM_STACKTRACE_H */
>> diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c
>> index 88ff471b0bce..f459208149ae 100644
>> --- a/arch/arm64/kernel/perf_callchain.c
>> +++ b/arch/arm64/kernel/perf_callchain.c
>> @@ -148,13 +148,16 @@ void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
>>  			   struct pt_regs *regs)
>>  {
>>  	struct stackframe frame;
>> +	enum unwind_rc rc;
>>  
>>  	if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
>>  		/* We don't support guest os callchain now */
>>  		return;
>>  	}
>>  
>> -	start_backtrace(&frame, regs->regs[29], regs->pc);
>> +	rc = start_backtrace(&frame, regs->regs[29], regs->pc);
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return;
>>  	walk_stackframe(current, &frame, callchain_trace, entry);
> 
> As a first step, could we convert this over to arch_stack_walk()?
> 

OK.

>>  }
>>  
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 6e60aa3b5ea9..e9c763b44fd4 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -573,6 +573,7 @@ unsigned long get_wchan(struct task_struct *p)
>>  	struct stackframe frame;
>>  	unsigned long stack_page, ret = 0;
>>  	int count = 0;
>> +	enum unwind_rc rc;
>>  	if (!p || p == current || p->state == TASK_RUNNING)
>>  		return 0;
>>  
>> @@ -580,10 +581,13 @@ unsigned long get_wchan(struct task_struct *p)
>>  	if (!stack_page)
>>  		return 0;
>>  
>> -	start_backtrace(&frame, thread_saved_fp(p), thread_saved_pc(p));
>> +	rc = start_backtrace(&frame, thread_saved_fp(p), thread_saved_pc(p));
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return 0;
>>  
>>  	do {
>> -		if (unwind_frame(p, &frame))
>> +		rc = unwind_frame(p, &frame);
>> +		if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>>  			goto out;
>>  		if (!in_sched_functions(frame.pc)) {
>>  			ret = frame.pc;
> 
> Likewise, can we convert this to use arch_stack_walk()?
> 

OK.

>> diff --git a/arch/arm64/kernel/return_address.c b/arch/arm64/kernel/return_address.c
>> index a6d18755652f..1224e043e98f 100644
>> --- a/arch/arm64/kernel/return_address.c
>> +++ b/arch/arm64/kernel/return_address.c
>> @@ -36,13 +36,17 @@ void *return_address(unsigned int level)
>>  {
>>  	struct return_address_data data;
>>  	struct stackframe frame;
>> +	enum unwind_rc rc;
>>  
>>  	data.level = level + 2;
>>  	data.addr = NULL;
>>  
>> -	start_backtrace(&frame,
>> -			(unsigned long)__builtin_frame_address(0),
>> -			(unsigned long)return_address);
>> +	rc = start_backtrace(&frame,
>> +			     (unsigned long)__builtin_frame_address(0),
>> +			     (unsigned long)return_address);
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return NULL;
>> +
>>  	walk_stackframe(current, &frame, save_return_addr, &data);
> 
> Likewise, can we convert this to use arch_stack_walk()?
> 

OK.

Thanks.

Madhavan

WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: broonie@kernel.org, jpoimboe@redhat.com, ardb@kernel.org,
	nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com,
	catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org,
	pasha.tatashin@soleen.com, jthierry@redhat.com,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v6 1/3] arm64: Improve the unwinder return value
Date: Thu, 29 Jul 2021 08:54:58 -0500	[thread overview]
Message-ID: <52686cb6-573c-03ca-06c2-67ae07c91243@linux.microsoft.com> (raw)
In-Reply-To: <20210728165635.GA47345@C02TD0UTHF1T.local>

Thanks for the review. Responses inline...

On 7/28/21 11:56 AM, Mark Rutland wrote:
> On Wed, Jun 30, 2021 at 05:33:54PM -0500, madvenka@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>>
>> Currently, the unwinder returns a tri-state return value:
>>
>> 	0		means "continue with the unwind"
>> 	-ENOENT		means "successful termination of the stack trace"
>> 	-EINVAL		means "fatal error, abort the stack trace"
>>
>> This is confusing. To fix this, define an enumeration of different return
>> codes to make it clear. Handle the return codes in all of the unwind
>> consumers.
> 
> I agree the tri-state is confusing, and I also generally agree that
> enums are preferabel to a set of error codes. However, I don't think
> this is quite the right abstraction; more on that below.
> 

OK.

>>
>> Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
>> ---
>>  arch/arm64/include/asm/stacktrace.h | 14 ++++++--
>>  arch/arm64/kernel/perf_callchain.c  |  5 ++-
>>  arch/arm64/kernel/process.c         |  8 +++--
>>  arch/arm64/kernel/return_address.c  | 10 ++++--
>>  arch/arm64/kernel/stacktrace.c      | 53 ++++++++++++++++-------------
>>  arch/arm64/kernel/time.c            |  9 +++--
>>  6 files changed, 64 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
>> index eb29b1fe8255..6fcd58553fb1 100644
>> --- a/arch/arm64/include/asm/stacktrace.h
>> +++ b/arch/arm64/include/asm/stacktrace.h
>> @@ -30,6 +30,12 @@ struct stack_info {
>>  	enum stack_type type;
>>  };
>>  
>> +enum unwind_rc {
>> +	UNWIND_CONTINUE,		/* No errors encountered */
>> +	UNWIND_ABORT,			/* Fatal errors encountered */
>> +	UNWIND_FINISH,			/* End of stack reached successfully */
>> +};
> 
> Generally, there are a bunch of properties we might need to check for an
> unwind step relating to reliabiltiy (e.g. as you add
> UNWIND_CONTINUE_WITH_RISK in the next patch), and I'd prefer that we
> check those properties on the struct stackframe, and simplify
> unwind_frame() to return a bool.
> 
> Something akin to the x86 unwinders, where the main loop looks like:
> 
> for (unwind_start(&state, ...);
>      !unwind_done(&state) && !unwind_error(&state);
>      unwind_next_frame(&state) {
> 	...
> }
> 
> That way we don't have to grow the enum to handle every variation that
> we can think of, and it's simple enough for users to check the
> properties with the helpers.
> 

I can do that.

>> +
>>  /*
>>   * A snapshot of a frame record or fp/lr register values, along with some
>>   * accounting information necessary for robust unwinding.
>> @@ -61,7 +67,8 @@ struct stackframe {
>>  #endif
>>  };
>>  
>> -extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
>> +extern enum unwind_rc unwind_frame(struct task_struct *tsk,
>> +				   struct stackframe *frame);
>>  extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
>>  			    bool (*fn)(void *, unsigned long), void *data);
>>  extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> @@ -148,8 +155,8 @@ static inline bool on_accessible_stack(const struct task_struct *tsk,
>>  	return false;
>>  }
>>  
>> -static inline void start_backtrace(struct stackframe *frame,
>> -				   unsigned long fp, unsigned long pc)
>> +static inline enum unwind_rc start_backtrace(struct stackframe *frame,
>> +					     unsigned long fp, unsigned long pc)
>>  {
>>  	frame->fp = fp;
>>  	frame->pc = pc;
>> @@ -169,6 +176,7 @@ static inline void start_backtrace(struct stackframe *frame,
>>  	bitmap_zero(frame->stacks_done, __NR_STACK_TYPES);
>>  	frame->prev_fp = 0;
>>  	frame->prev_type = STACK_TYPE_UNKNOWN;
>> +	return UNWIND_CONTINUE;
>>  }
>>  
>>  #endif	/* __ASM_STACKTRACE_H */
>> diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c
>> index 88ff471b0bce..f459208149ae 100644
>> --- a/arch/arm64/kernel/perf_callchain.c
>> +++ b/arch/arm64/kernel/perf_callchain.c
>> @@ -148,13 +148,16 @@ void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
>>  			   struct pt_regs *regs)
>>  {
>>  	struct stackframe frame;
>> +	enum unwind_rc rc;
>>  
>>  	if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
>>  		/* We don't support guest os callchain now */
>>  		return;
>>  	}
>>  
>> -	start_backtrace(&frame, regs->regs[29], regs->pc);
>> +	rc = start_backtrace(&frame, regs->regs[29], regs->pc);
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return;
>>  	walk_stackframe(current, &frame, callchain_trace, entry);
> 
> As a first step, could we convert this over to arch_stack_walk()?
> 

OK.

>>  }
>>  
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 6e60aa3b5ea9..e9c763b44fd4 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -573,6 +573,7 @@ unsigned long get_wchan(struct task_struct *p)
>>  	struct stackframe frame;
>>  	unsigned long stack_page, ret = 0;
>>  	int count = 0;
>> +	enum unwind_rc rc;
>>  	if (!p || p == current || p->state == TASK_RUNNING)
>>  		return 0;
>>  
>> @@ -580,10 +581,13 @@ unsigned long get_wchan(struct task_struct *p)
>>  	if (!stack_page)
>>  		return 0;
>>  
>> -	start_backtrace(&frame, thread_saved_fp(p), thread_saved_pc(p));
>> +	rc = start_backtrace(&frame, thread_saved_fp(p), thread_saved_pc(p));
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return 0;
>>  
>>  	do {
>> -		if (unwind_frame(p, &frame))
>> +		rc = unwind_frame(p, &frame);
>> +		if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>>  			goto out;
>>  		if (!in_sched_functions(frame.pc)) {
>>  			ret = frame.pc;
> 
> Likewise, can we convert this to use arch_stack_walk()?
> 

OK.

>> diff --git a/arch/arm64/kernel/return_address.c b/arch/arm64/kernel/return_address.c
>> index a6d18755652f..1224e043e98f 100644
>> --- a/arch/arm64/kernel/return_address.c
>> +++ b/arch/arm64/kernel/return_address.c
>> @@ -36,13 +36,17 @@ void *return_address(unsigned int level)
>>  {
>>  	struct return_address_data data;
>>  	struct stackframe frame;
>> +	enum unwind_rc rc;
>>  
>>  	data.level = level + 2;
>>  	data.addr = NULL;
>>  
>> -	start_backtrace(&frame,
>> -			(unsigned long)__builtin_frame_address(0),
>> -			(unsigned long)return_address);
>> +	rc = start_backtrace(&frame,
>> +			     (unsigned long)__builtin_frame_address(0),
>> +			     (unsigned long)return_address);
>> +	if (rc == UNWIND_FINISH || rc == UNWIND_ABORT)
>> +		return NULL;
>> +
>>  	walk_stackframe(current, &frame, save_return_addr, &data);
> 
> Likewise, can we convert this to use arch_stack_walk()?
> 

OK.

Thanks.

Madhavan

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

  reply	other threads:[~2021-07-29 13:55 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3f2aab69a35c243c5e97f47c4ad84046355f5b90>
2021-06-30 22:33 ` [RFC PATCH v6 0/3] arm64: Implement stack trace reliability checks madvenka
2021-06-30 22:33   ` madvenka
2021-06-30 22:33   ` [RFC PATCH v6 1/3] arm64: Improve the unwinder return value madvenka
2021-06-30 22:33     ` madvenka
2021-07-28 16:56     ` Mark Rutland
2021-07-28 16:56       ` Mark Rutland
2021-07-29 13:54       ` Madhavan T. Venkataraman [this message]
2021-07-29 13:54         ` Madhavan T. Venkataraman
2021-06-30 22:33   ` [RFC PATCH v6 2/3] arm64: Introduce stack trace reliability checks in the unwinder madvenka
2021-06-30 22:33     ` madvenka
2021-06-30 22:33   ` [RFC PATCH v6 3/3] arm64: Create a list of SYM_CODE functions, check return PC against list madvenka
2021-06-30 22:33     ` madvenka
2021-07-28 17:25     ` Mark Rutland
2021-07-28 17:25       ` Mark Rutland
2021-07-29 14:06       ` Madhavan T. Venkataraman
2021-07-29 14:06         ` Madhavan T. Venkataraman
2021-07-29 14:52         ` Mark Brown
2021-07-29 14:52           ` Mark Brown
2021-07-29 17:07           ` Madhavan T. Venkataraman
2021-07-29 17:07             ` Madhavan T. Venkataraman
2021-07-29 15:48         ` Mark Rutland
2021-07-29 15:48           ` Mark Rutland
2021-07-29 16:27           ` Mark Brown
2021-07-29 16:27             ` Mark Brown
2021-07-29 17:09           ` Madhavan T. Venkataraman
2021-07-29 17:09             ` Madhavan T. Venkataraman
2021-07-26 13:49   ` [RFC PATCH v6 0/3] arm64: Implement stack trace reliability checks Madhavan T. Venkataraman
2021-07-26 13:49     ` Madhavan T. Venkataraman
2021-08-12 13:24 ` [RFC PATCH v7 0/4] arm64: Reorganize the unwinder and implement " madvenka
2021-08-12 13:24   ` madvenka
2021-08-12 13:24   ` [RFC PATCH v7 1/4] arm64: Make all stack walking functions use arch_stack_walk() madvenka
2021-08-12 13:24     ` madvenka
2021-08-12 15:23     ` Mark Brown
2021-08-12 15:23       ` Mark Brown
2021-08-12 16:30       ` Madhavan T. Venkataraman
2021-08-12 16:30         ` Madhavan T. Venkataraman
2021-08-12 20:59     ` kernel test robot
2021-08-12 13:24   ` [RFC PATCH v7 2/4] arm64: Reorganize the unwinder code for better consistency and maintenance madvenka
2021-08-12 13:24     ` madvenka
2021-08-12 13:24   ` [RFC PATCH v7 3/4] arm64: Introduce stack trace reliability checks in the unwinder madvenka
2021-08-12 13:24     ` madvenka
2021-08-12 13:24   ` [RFC PATCH v7 4/4] arm64: Create a list of SYM_CODE functions, check return PC against list madvenka
2021-08-12 13:24     ` madvenka
2021-08-12 18:53     ` kernel test robot
2021-08-12 18:31   ` [RFC PATCH v7 0/4] arm64: Reorganize the unwinder and implement stack trace reliability checks Madhavan T. Venkataraman
2021-08-12 18:31     ` Madhavan T. Venkataraman
2021-08-12 18:45     ` Madhavan T. Venkataraman
2021-08-12 18:45       ` Madhavan T. Venkataraman
2021-08-12 18:35 ` madvenka
2021-08-12 18:35   ` madvenka
2021-08-12 18:35   ` [RFC PATCH v7 1/4] arm64: Make all stack walking functions use arch_stack_walk() madvenka
2021-08-12 18:35     ` madvenka
2021-08-12 18:35   ` [RFC PATCH v7 2/4] arm64: Reorganize the unwinder code for better consistency and maintenance madvenka
2021-08-12 18:35     ` madvenka
2021-08-12 18:35   ` [RFC PATCH v7 3/4] arm64: Introduce stack trace reliability checks in the unwinder madvenka
2021-08-12 18:35     ` madvenka
2021-08-12 18:35   ` [RFC PATCH v7 4/4] arm64: Create a list of SYM_CODE functions, check return PC against list madvenka
2021-08-12 18:35     ` madvenka

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=52686cb6-573c-03ca-06c2-67ae07c91243@linux.microsoft.com \
    --to=madvenka@linux.microsoft.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jmorris@namei.org \
    --cc=jpoimboe@redhat.com \
    --cc=jthierry@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nobuta.keiya@fujitsu.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=sjitindarsingh@gmail.com \
    --cc=will@kernel.org \
    /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.