All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksa Sarai <asarai@suse.de>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Brendan Gregg <bgregg@netflix.com>,
	Christian Brauner <christian@brauner.io>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Mon, 12 Nov 2018 21:38:22 +1100	[thread overview]
Message-ID: <20181112103822.ktd4fx7o4cqpfk4q@mikami> (raw)
In-Reply-To: <20181111003137.c9df7a077d983cde57c06ee8@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

On 2018-11-11, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > > +		addr = kretprobe_ret_addr(current, addr, stack_addr(regs));
> > > 
> > > But since kretprobe will be an event, which can kick the stackdump.
> > > BTW, from kretprobe, regs->ip should always be the trampoline handler, 
> > > see arch/x86/kernel/kprobes/core.c:772 :-)
> > > So it must be fixed always.
> > 
> > Right, but kretprobe_ret_addr() is returning the *original* return
> > address (and we need to do an (addr == kretprobe_trampoline)). The
> > real problem is that stack_addr(regs) isn't the same as it is during
> > kretprobe setup (but kretprobe_ret_addr() works everywhere else).
> 
> I think stack_addr(regs) should be same when this is called from kretprobe
> handler context. Otherwise, yes, it is not same, but in that case, regs->ip
> is not kretprobe_trampoline too.

I figured it out.

It should be (regs->sp - 1) (just like it is inside the relevant
unwinder function for ORC). I now have a prototype which works under the
frame unwinder[*] -- however under ORC you can only see the top-most
function (the unwinder doesn't see the other function calls). I'm
playing with ORC hints with kretprobe_trampoline to try to improve
things but it's still a bit screwy.


[*]: However, I've noticed that the stack traces between the two traces
	 no longer match. On kprobe you get function_name+1, but on
	 kretprobe you get function_caller+foo. Obviously it's working but
	 the return address results in slightly different stack traces. This
	 means that stack trace aggregation between kprobe and kretprobe
	 won't work anymore -- at least not like it did in my original
	 patch. So I'm really not sure where to go from here.

I can send around another patchset to illustrate the problem if you like
(as well as show how the current unwinding code works).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <asarai@suse.de>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Brendan Gregg <bgregg@netflix.com>,
	Christian Brauner <christian@brauner.io>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel
Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Mon, 12 Nov 2018 21:38:22 +1100	[thread overview]
Message-ID: <20181112103822.ktd4fx7o4cqpfk4q@mikami> (raw)
In-Reply-To: <20181111003137.c9df7a077d983cde57c06ee8@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

On 2018-11-11, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > > +		addr = kretprobe_ret_addr(current, addr, stack_addr(regs));
> > > 
> > > But since kretprobe will be an event, which can kick the stackdump.
> > > BTW, from kretprobe, regs->ip should always be the trampoline handler, 
> > > see arch/x86/kernel/kprobes/core.c:772 :-)
> > > So it must be fixed always.
> > 
> > Right, but kretprobe_ret_addr() is returning the *original* return
> > address (and we need to do an (addr == kretprobe_trampoline)). The
> > real problem is that stack_addr(regs) isn't the same as it is during
> > kretprobe setup (but kretprobe_ret_addr() works everywhere else).
> 
> I think stack_addr(regs) should be same when this is called from kretprobe
> handler context. Otherwise, yes, it is not same, but in that case, regs->ip
> is not kretprobe_trampoline too.

I figured it out.

It should be (regs->sp - 1) (just like it is inside the relevant
unwinder function for ORC). I now have a prototype which works under the
frame unwinder[*] -- however under ORC you can only see the top-most
function (the unwinder doesn't see the other function calls). I'm
playing with ORC hints with kretprobe_trampoline to try to improve
things but it's still a bit screwy.


[*]: However, I've noticed that the stack traces between the two traces
	 no longer match. On kprobe you get function_name+1, but on
	 kretprobe you get function_caller+foo. Obviously it's working but
	 the return address results in slightly different stack traces. This
	 means that stack trace aggregation between kprobe and kretprobe
	 won't work anymore -- at least not like it did in my original
	 patch. So I'm really not sure where to go from here.

I can send around another patchset to illustrate the problem if you like
(as well as show how the current unwinding code works).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: asarai at suse.de (Aleksa Sarai)
Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Mon, 12 Nov 2018 21:38:22 +1100	[thread overview]
Message-ID: <20181112103822.ktd4fx7o4cqpfk4q@mikami> (raw)
In-Reply-To: <20181111003137.c9df7a077d983cde57c06ee8@kernel.org>

On 2018-11-11, Masami Hiramatsu <mhiramat at kernel.org> wrote:
> > > > +		addr = kretprobe_ret_addr(current, addr, stack_addr(regs));
> > > 
> > > But since kretprobe will be an event, which can kick the stackdump.
> > > BTW, from kretprobe, regs->ip should always be the trampoline handler, 
> > > see arch/x86/kernel/kprobes/core.c:772 :-)
> > > So it must be fixed always.
> > 
> > Right, but kretprobe_ret_addr() is returning the *original* return
> > address (and we need to do an (addr == kretprobe_trampoline)). The
> > real problem is that stack_addr(regs) isn't the same as it is during
> > kretprobe setup (but kretprobe_ret_addr() works everywhere else).
> 
> I think stack_addr(regs) should be same when this is called from kretprobe
> handler context. Otherwise, yes, it is not same, but in that case, regs->ip
> is not kretprobe_trampoline too.

I figured it out.

It should be (regs->sp - 1) (just like it is inside the relevant
unwinder function for ORC). I now have a prototype which works under the
frame unwinder[*] -- however under ORC you can only see the top-most
function (the unwinder doesn't see the other function calls). I'm
playing with ORC hints with kretprobe_trampoline to try to improve
things but it's still a bit screwy.


[*]: However, I've noticed that the stack traces between the two traces
	 no longer match. On kprobe you get function_name+1, but on
	 kretprobe you get function_caller+foo. Obviously it's working but
	 the return address results in slightly different stack traces. This
	 means that stack trace aggregation between kprobe and kretprobe
	 won't work anymore -- at least not like it did in my original
	 patch. So I'm really not sure where to go from here.

I can send around another patchset to illustrate the problem if you like
(as well as show how the current unwinding code works).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linaro.org/pipermail/linux-kselftest-mirror/attachments/20181112/562e3359/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: asarai@suse.de (Aleksa Sarai)
Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Mon, 12 Nov 2018 21:38:22 +1100	[thread overview]
Message-ID: <20181112103822.ktd4fx7o4cqpfk4q@mikami> (raw)
Message-ID: <20181112103822.4S7q-1ssQ_rns6FR2VJhlbKNukihOPZIvdX1xzc3azY@z> (raw)
In-Reply-To: <20181111003137.c9df7a077d983cde57c06ee8@kernel.org>

On 2018-11-11, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > > +		addr = kretprobe_ret_addr(current, addr, stack_addr(regs));
> > > 
> > > But since kretprobe will be an event, which can kick the stackdump.
> > > BTW, from kretprobe, regs->ip should always be the trampoline handler, 
> > > see arch/x86/kernel/kprobes/core.c:772 :-)
> > > So it must be fixed always.
> > 
> > Right, but kretprobe_ret_addr() is returning the *original* return
> > address (and we need to do an (addr == kretprobe_trampoline)). The
> > real problem is that stack_addr(regs) isn't the same as it is during
> > kretprobe setup (but kretprobe_ret_addr() works everywhere else).
> 
> I think stack_addr(regs) should be same when this is called from kretprobe
> handler context. Otherwise, yes, it is not same, but in that case, regs->ip
> is not kretprobe_trampoline too.

I figured it out.

It should be (regs->sp - 1) (just like it is inside the relevant
unwinder function for ORC). I now have a prototype which works under the
frame unwinder[*] -- however under ORC you can only see the top-most
function (the unwinder doesn't see the other function calls). I'm
playing with ORC hints with kretprobe_trampoline to try to improve
things but it's still a bit screwy.


[*]: However, I've noticed that the stack traces between the two traces
	 no longer match. On kprobe you get function_name+1, but on
	 kretprobe you get function_caller+foo. Obviously it's working but
	 the return address results in slightly different stack traces. This
	 means that stack trace aggregation between kprobe and kretprobe
	 won't work anymore -- at least not like it did in my original
	 patch. So I'm really not sure where to go from here.

I can send around another patchset to illustrate the problem if you like
(as well as show how the current unwinding code works).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linaro.org/pipermail/linux-kselftest-mirror/attachments/20181112/562e3359/attachment.sig>

  reply	other threads:[~2018-11-12 10:36 UTC|newest]

Thread overview: 137+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  8:35 [PATCH v3 0/2] kretprobe: produce sane stack traces Aleksa Sarai
2018-11-01  8:35 ` Aleksa Sarai
2018-11-01  8:35 ` cyphar
2018-11-01  8:35 ` [PATCH v3 1/2] " Aleksa Sarai
2018-11-01  8:35   ` Aleksa Sarai
2018-11-01  8:35   ` cyphar
2018-11-01 15:20   ` Masami Hiramatsu
2018-11-01 15:20     ` Masami Hiramatsu
2018-11-01 15:20     ` mhiramat
2018-11-01 15:20     ` Masami Hiramatsu
2018-11-01 21:13     ` Aleksa Sarai
2018-11-01 21:13       ` Aleksa Sarai
2018-11-01 21:13       ` cyphar
2018-11-01 21:13       ` Aleksa Sarai
2018-11-02  3:04       ` Masami Hiramatsu
2018-11-02  3:04         ` Masami Hiramatsu
2018-11-02  3:04         ` mhiramat
2018-11-02  3:04         ` Masami Hiramatsu
2018-11-02  4:37         ` Aleksa Sarai
2018-11-02  4:37           ` Aleksa Sarai
2018-11-02  4:37           ` cyphar
2018-11-02  4:37           ` Aleksa Sarai
2018-11-03 12:47           ` Masami Hiramatsu
2018-11-03 12:47             ` Masami Hiramatsu
2018-11-03 12:47             ` mhiramat
2018-11-03 12:47             ` Masami Hiramatsu
2018-11-02  0:47   ` Steven Rostedt
2018-11-02  0:47     ` Steven Rostedt
2018-11-02  0:47     ` rostedt
2018-11-02  0:47     ` Steven Rostedt
2018-11-02  5:05     ` Aleksa Sarai
2018-11-02  5:05       ` Aleksa Sarai
2018-11-02  5:05       ` cyphar
2018-11-02  5:05       ` Aleksa Sarai
2018-11-02  6:59       ` Aleksa Sarai
2018-11-02  6:59         ` Aleksa Sarai
2018-11-02  6:59         ` cyphar
2018-11-02  6:59         ` Aleksa Sarai
2018-11-02 13:16         ` Steven Rostedt
2018-11-02 13:16           ` Steven Rostedt
2018-11-02 13:16           ` rostedt
2018-11-02 13:16           ` Steven Rostedt
2018-11-02 15:43           ` Josh Poimboeuf
2018-11-02 15:43             ` Josh Poimboeuf
2018-11-02 15:43             ` jpoimboe
2018-11-02 15:43             ` Josh Poimboeuf
2018-11-02 16:13             ` Steven Rostedt
2018-11-02 16:13               ` Steven Rostedt
2018-11-02 16:13               ` rostedt
2018-11-02 16:13               ` Steven Rostedt
2018-11-03 13:00               ` Masami Hiramatsu
2018-11-03 13:00                 ` Masami Hiramatsu
2018-11-03 13:00                 ` mhiramat
2018-11-03 13:00                 ` Masami Hiramatsu
2018-11-03 13:13                 ` Steven Rostedt
2018-11-03 13:13                   ` Steven Rostedt
2018-11-03 13:13                   ` rostedt
2018-11-03 13:13                   ` Steven Rostedt
2018-11-03 16:34                   ` Masami Hiramatsu
2018-11-03 16:34                     ` Masami Hiramatsu
2018-11-03 16:34                     ` mhiramat
2018-11-03 16:34                     ` Masami Hiramatsu
2018-11-03 17:30                     ` Steven Rostedt
2018-11-03 17:30                       ` Steven Rostedt
2018-11-03 17:30                       ` rostedt
2018-11-03 17:30                       ` Steven Rostedt
2018-11-03 17:33                       ` Steven Rostedt
2018-11-03 17:33                         ` Steven Rostedt
2018-11-03 17:33                         ` rostedt
2018-11-03 17:33                         ` Steven Rostedt
2018-11-04  2:25                       ` Masami Hiramatsu
2018-11-04  2:25                         ` Masami Hiramatsu
2018-11-04  2:25                         ` mhiramat
2018-11-04  2:25                         ` Masami Hiramatsu
2018-11-03  7:02           ` Aleksa Sarai
2018-11-03  7:02             ` Aleksa Sarai
2018-11-03  7:02             ` cyphar
2018-11-03  7:02             ` Aleksa Sarai
2018-11-04 11:59             ` Aleksa Sarai
2018-11-04 11:59               ` Aleksa Sarai
2018-11-04 11:59               ` cyphar
2018-11-04 11:59               ` Aleksa Sarai
2018-11-06 22:15               ` Steven Rostedt
2018-11-06 22:15                 ` Steven Rostedt
2018-11-06 22:15                 ` rostedt
2018-11-06 22:15                 ` Steven Rostedt
2018-11-08  7:46                 ` Aleksa Sarai
2018-11-08  7:46                   ` Aleksa Sarai
2018-11-08  7:46                   ` cyphar
2018-11-08  7:46                   ` Aleksa Sarai
2018-11-08  8:04                   ` Aleksa Sarai
2018-11-08  8:04                     ` Aleksa Sarai
2018-11-08  8:04                     ` cyphar
2018-11-08  8:04                     ` Aleksa Sarai
2018-11-08 14:44                     ` Josh Poimboeuf
2018-11-08 14:44                       ` Josh Poimboeuf
2018-11-08 14:44                       ` jpoimboe
2018-11-08 14:44                       ` Josh Poimboeuf
2018-11-09  7:26                       ` Masami Hiramatsu
2018-11-09  7:26                         ` Masami Hiramatsu
2018-11-09  7:26                         ` mhiramat
2018-11-09  7:26                         ` Masami Hiramatsu
2018-11-09 15:10                         ` Aleksa Sarai
2018-11-09 15:10                           ` Aleksa Sarai
2018-11-09 15:10                           ` asarai
2018-11-09 15:10                           ` Aleksa Sarai
2018-11-09  7:15                     ` Masami Hiramatsu
2018-11-09  7:15                       ` Masami Hiramatsu
2018-11-09  7:15                       ` mhiramat
2018-11-09  7:15                       ` Masami Hiramatsu
2018-11-09 15:06                       ` Aleksa Sarai
2018-11-09 15:06                         ` Aleksa Sarai
2018-11-09 15:06                         ` asarai
2018-11-09 15:06                         ` Aleksa Sarai
2018-11-10 15:31                         ` Masami Hiramatsu
2018-11-10 15:31                           ` Masami Hiramatsu
2018-11-10 15:31                           ` mhiramat
2018-11-10 15:31                           ` Masami Hiramatsu
2018-11-12 10:38                           ` Aleksa Sarai [this message]
2018-11-12 10:38                             ` Aleksa Sarai
2018-11-12 10:38                             ` asarai
2018-11-12 10:38                             ` Aleksa Sarai
2018-11-03 13:23           ` Masami Hiramatsu
2018-11-03 13:23             ` Masami Hiramatsu
2018-11-03 13:23             ` mhiramat
2018-11-03 13:23             ` Masami Hiramatsu
2018-11-02  7:58       ` Aleksa Sarai
2018-11-02  7:58         ` Aleksa Sarai
2018-11-02  7:58         ` cyphar
2018-11-02  7:58         ` Aleksa Sarai
2018-11-02  4:01   ` kbuild test robot
2018-11-02  4:01     ` kbuild test robot
2018-11-02  4:01     ` lkp
2018-11-02  4:01     ` kbuild test robot
2018-11-01  8:35 ` [PATCH v3 2/2] trace: remove kretprobed checks Aleksa Sarai
2018-11-01  8:35   ` Aleksa Sarai
2018-11-01  8:35   ` cyphar

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=20181112103822.ktd4fx7o4cqpfk4q@mikami \
    --to=asarai@suse.de \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=ast@kernel.org \
    --cc=bgregg@netflix.com \
    --cc=christian@brauner.io \
    --cc=corbet@lwn.net \
    --cc=cyphar@cyphar.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jolsa@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@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.