live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Wangshaobo (bobo)" <bobo.shaobowang@huawei.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: <huawei.libin@huawei.com>, <xiexiuqi@huawei.com>,
	<cj.chengjian@huawei.com>, <mingo@redhat.com>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, <live-patching@vger.kernel.org>,
	<mbenes@suse.cz>, <devel@etsukata.com>, <viro@zeniv.linux.org.uk>,
	<esyr@redhat.com>
Subject: Re: Question: livepatch failed for new fork() task stack unreliable
Date: Wed, 3 Jun 2020 22:06:07 +0800	[thread overview]
Message-ID: <1353648b-f3f7-5b8d-f0bb-28bdb1a66f0f@huawei.com> (raw)
In-Reply-To: <20200602131450.oydrydelpdaval4h@treble>


在 2020/6/2 21:14, Josh Poimboeuf 写道:
> On Tue, Jun 02, 2020 at 09:22:30AM +0800, Wangshaobo (bobo) wrote:
>> so i think this question is related to ORC unwinder, could i ask if you have
>> strategy or plan to avoid this problem ?
> I suspect something like this would fix it (untested):
>
> diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
> index 6ad43fc44556..8cf95ded1410 100644
> --- a/arch/x86/kernel/stacktrace.c
> +++ b/arch/x86/kernel/stacktrace.c
> @@ -50,7 +50,7 @@ int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry,
>   		if (regs) {
>   			/* Success path for user tasks */
>   			if (user_mode(regs))
> -				return 0;
> +				break;
>   
>   			/*
>   			 * Kernel mode registers on the stack indicate an
> @@ -81,10 +81,6 @@ int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry,
>   	if (unwind_error(&state))
>   		return -EINVAL;
>   
> -	/* Success path for non-user tasks, i.e. kthreads and idle tasks */
> -	if (!(task->flags & (PF_KTHREAD | PF_IDLE)))
> -		return -EINVAL;
> -
>   	return 0;
>   }
>   
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index 7f969b2d240f..d7396431261a 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -540,7 +540,7 @@ bool unwind_next_frame(struct unwind_state *state)
>   		state->sp = sp;
>   		state->regs = NULL;
>   		state->prev_regs = NULL;
> -		state->signal = false;
> +		state->signal = ((void *)state->ip == ret_from_fork);
>   		break;
>   
>   	case ORC_TYPE_REGS:

what a awesome job, thanks a lot, Josh

Today I test your fix, but arch_stack_walk_reliable() still return 
failed sometimes, I

found one of three scenarios mentioned failed:


1. user task (just fork) but not been scheduled

     test FAILED

     it is because unwind_next_frame() get the first frame, this time 
state->signal is false, and then return

     failed in the same place for ret_from_fork has not executed at all.


2. user task (just fork) start excuting ret_from_fork() till 
schedule_tail but not UNWIND_HINT_REGS

     test condition :loop fork() in current  system

     result : SUCCESS,

     it looks like this modification works for my perspective :

	-	/* Success path for non-user tasks, i.e. kthreads and idle tasks */
	-	if (!(task->flags & (PF_KTHREAD | PF_IDLE)))
	-		return -EINVAL;
   but is this possible to miss one invalid judgement condition ? (1)

3. call_usermodehelper_exec_async

     test condition :loop call call_usermodehelper() in a module selfmade.

     result : SUCCESS,

    it looks state->signal==true works when unwind_next_frame() gets the 
end ret_from_fork() frame,

    but i don't know how does it work, i am confused by this sentences, 
how does the comment means sibling calls and

     calls to noreturn functions? (2)

             /*
              * Find the orc_entry associated with the text address.
              *
              * Decrement call return addresses by one so they work for 
sibling
              * calls and calls to noreturn functions.
              */
             orc = orc_find(state->signal ? state->ip : state->ip - 1);
             if (!orc) {


So i slightly modify your code, i move  state->signal = ((void 
*)state->ip == ret_from_fork) to unwind_start()

and render unwind_next_frame() remain the same as before:

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index e9cc182aa97e..ecce5051e8fd 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -620,6 +620,7 @@ void __unwind_start(struct unwind_state *state, 
struct task_struct *task,
                 state->sp = task->thread.sp;
                 state->bp = READ_ONCE_NOCHECK(frame->bp);
                 state->ip = READ_ONCE_NOCHECK(frame->ret_addr);
+              state->signal = ((void *)state->ip == ret_from_fork);
         }

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 7f969b2d240f..d7396431261a 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -540,7 +540,7 @@ bool unwind_next_frame(struct unwind_state *state)
  		state->sp = sp;
  		state->regs = NULL;
  		state->prev_regs = NULL;
-		state->signal = ((void *)state->ip == ret_from_fork);
+		state->signal = false;
  		break;


After modification all the three scenarios are captured and no longer 
return failed,  but i don't know

how does it affect the scenarios 3, because current frame->ret_addr(the 
first frame) is not ret_from_fork,

it should return failed as scenarios1, but it didn't , i really want to 
know the reason. (3)


thanks again

Wang ShaoBo



  reply	other threads:[~2020-06-03 14:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 10:10 Question: livepatch failed for new fork() task stack unreliable Wang ShaoBo
2020-05-29 17:44 ` Josh Poimboeuf
     [not found]   ` <a9ed9157-f3cf-7d2c-7a8e-56150a2a114e@huawei.com>
2020-06-01 18:05     ` Josh Poimboeuf
2020-06-02  1:22       ` Wangshaobo (bobo)
2020-06-02 13:14         ` Josh Poimboeuf
2020-06-03 14:06           ` Wangshaobo (bobo) [this message]
2020-06-03 15:33             ` Josh Poimboeuf
2020-06-04  1:24               ` Wangshaobo (bobo)
2020-06-04  2:40                 ` Josh Poimboeuf
2020-06-05  1:26                   ` Wangshaobo (bobo)
2020-06-05  1:51                     ` Josh Poimboeuf
2020-06-30 13:04                       ` Wangshaobo (bobo)
2020-06-30 21:36                         ` Josh Poimboeuf

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=1353648b-f3f7-5b8d-f0bb-28bdb1a66f0f@huawei.com \
    --to=bobo.shaobowang@huawei.com \
    --cc=cj.chengjian@huawei.com \
    --cc=devel@etsukata.com \
    --cc=esyr@redhat.com \
    --cc=huawei.libin@huawei.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    --cc=xiexiuqi@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).