From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Wang Nan <wangnan0@huawei.co>, Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, Wang Nan <wangnan0@huawei.com>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH 2/2] perf tools: Fix fault in error patch of intel_pt_process_auxtrace_info()
Date: Tue, 2 Feb 2016 17:38:04 -0300 [thread overview]
Message-ID: <20160202203804.GH32488@kernel.org> (raw)
In-Reply-To: <20160202155225.GD32488@kernel.org>
Em Tue, Feb 02, 2016 at 12:52:25PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Feb 02, 2016 at 12:24:19PM +0200, Adrian Hunter escreveu:
> > This patch does not fix the problem because the thread__zput() will still
> > segfault later if the error path is not taken.
> >
> > Sorry, I didn't look closely at this patch because I was not expecting it
> > to be taken because of the fix I had already sent:
> >
> > http://marc.info/?l=linux-kernel&m=145431692623940
> >
> > However if you want to keep the struct thread rbtree / list union, the
> > simple fix would be to reinstate the list initialization in this particular
> > case i.e.:
>
> So, can I go with the following patch+description+authorship?
BTW, I just noticed it while testing some unrelated patch (Jiri's hpp
hists stuff) that with a perf.data file with intel pt data, I get this
at the end of a TUI session, i.e. the segfault at tool exit:
Available samples
0 intel_pt/tsc=1,noretcomp=1/u ◆
29 sched:sched_switch ▒
0 dummy:u ▒
6 instructions:u ▒
0 transactions ▒
Program received signal SIGSEGV, Segmentation fault. ▒
0x00000000004ec5c5 in __write_once_size (size=8, res=0x7fffffffc2e0, p=0x0) at /home/acme/git/linux/tools/include/linux/compiler.h:82 ▒
82 case 8: *(volatile __u64_alias_t *) p = *(__u64_alias_t *) res; break; ▒
Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.4.5-1.fc23.x86_64 bzip2-libs-1.0.6-19.fc23.x86_64 elfutils-libelf-0.165-2.fc23.x86_64 elfutils-libs-0.165-2.fc23.x86_64 libunwind-1.1-10.fc23.x86_64 nss-softokn-freebl-3.21.0-1.1.fc23.x86_64 numactl-libs-2.0.10-3.fc23.x86_64 perl-libs-5.22.1-350.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64 slang-2.3.0-4.fc23.x86_64 xz-libs-5.2.1-3.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64 ▒
(gdb) bt ▒
#0 0x00000000004ec5c5 in __write_once_size (size=8, res=0x7fffffffc2e0, p=0x0) at /home/acme/git/linux/tools/include/linux/compiler.h:82 ▒
#1 __list_del (prev=0x0, next=0x1a2e970) at /home/acme/git/linux/tools/include/linux/list.h:89 ▒
#2 0x00000000004ec631 in __list_del_entry (entry=0x1a2e970) at /home/acme/git/linux/tools/include/linux/list.h:101 ▒
#3 0x00000000004ec6d2 in list_del_init (entry=0x1a2e970) at /home/acme/git/linux/tools/include/linux/list.h:144 ▒
#4 0x00000000004ecd2a in thread__put (thread=0x1a2e970) at util/thread.c:104 ▒
#5 0x000000000052de51 in intel_pt_free (session=0x19a3b90) at util/intel-pt.c:1747 ▒
#6 0x00000000004e4e3d in auxtrace__free (session=0x19a3b90) at util/auxtrace.h:513 ▒
#7 0x00000000004e5603 in perf_session__delete (session=0x19a3b90) at util/session.c:181 ▒
#8 0x00000000004363f3 in cmd_report (argc=0, argv=0x7fffffffdeb0, prefix=0x0) at builtin-report.c:984 ▒
#9 0x000000000049bea3 in run_builtin (p=0x8fa2c0 <commands+192>, argc=1, argv=0x7fffffffdeb0) at perf.c:390 ▒
#10 0x000000000049c10b in handle_internal_command (argc=1, argv=0x7fffffffdeb0) at perf.c:451 ▒
#11 0x000000000049c259 in run_argv (argcp=0x7fffffffdd0c, argv=0x7fffffffdd00) at perf.c:495 ▒
#12 0x000000000049c5eb in main (argc=1, argv=0x7fffffffdeb0) at perf.c:618 ▒
(gdb)
> From 3a4acda1ecbd290973de08250d7dcdfaf5b2fe0f Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Mon, 1 Feb 2016 03:21:04 +0000
> Subject: [PATCH 1/1] perf tools: Fix thread lifetime related segfaut in intel_pt
>
> intel_pt_process_auxtrace_info() creates a pt->unknown_thread thread
> that eventually needs to be freed by the last thread__put() on it, when
> its refcount hits zero, which may happen in
> intel_pt_process_auxtrace_info() error handling path and triggers the
> following segfault, which would happen as well at intel_pt_free, when
> tools using this intel_pt codebase frees up resources:
>
> # perf record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls
> 0 a anaconda-ks.cfg bin perf.data perf.data.old perf-f23-bringup.todo
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.217 MB perf.data ]
> #
> # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs
> Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field.
> intel_pt_synth_events: failed to synthesize 'instructions' event type
> Segmentation fault (core dumped)
> #
>
> The problem is: there's a union in 'struct thread' combines a list_head
> and a rb_node. The standard life cycle of a thread is: init rb_node in
> the constructor, insert it into machine->threads rbtree using rb_node,
> move it to machine->dead_threads using list_head, clean in the last
> thread__put: list_del_init(&thread->node).
>
> In the above command, it clean a thread before adding it into list,
> causes the above segfault.
>
> Since pt->unknown_thread will never live in an rbtree, initialize its
> list node so that when list_del_init() is done on it we don't segfault.
>
> After this patch:
>
> # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs
> Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field.
> intel_pt_synth_events: failed to synthesize 'instructions' event type
> 0x248 [0x88]: failed to process type: 70
> #
>
> Reported-by: Tong Zhang <ztong@vt.edu>
> Reported-by: Wang Nan <wangnan0@huawei.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Link: http://lkml.kernel.org/r/1454296865-19749-1-git-send-email-wangnan0@huawei.com
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
> tools/perf/util/intel-pt.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
> index 81a2eb77ba7f..05d815851be1 100644
> --- a/tools/perf/util/intel-pt.c
> +++ b/tools/perf/util/intel-pt.c
> @@ -2068,6 +2068,15 @@ int intel_pt_process_auxtrace_info(union perf_event *event,
> err = -ENOMEM;
> goto err_free_queues;
> }
> +
> + /*
> + * Since this thread will not be kept in any rbtree not in a
> + * list, initialize its list node so that at thread__put() the
> + * current thread lifetime assuption is kept and we don't segfault
> + * at list_del_init().
> + */
> + INIT_LIST_HEAD(&pt->unknown_thread->node);
> +
> err = thread__set_comm(pt->unknown_thread, "unknown", 0);
> if (err)
> goto err_delete_thread;
> --
> 2.5.0
>
next prev parent reply other threads:[~2016-02-02 20:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 17:13 [GIT PULL 0/2] perf/urgent fixes Arnaldo Carvalho de Melo
2016-02-01 17:13 ` [PATCH 1/2] perf tools: tracepoint_error() can receive e=NULL, robustify it Arnaldo Carvalho de Melo
2016-02-01 17:13 ` [PATCH 2/2] perf tools: Fix fault in error patch of intel_pt_process_auxtrace_info() Arnaldo Carvalho de Melo
2016-02-02 10:24 ` Adrian Hunter
2016-02-02 14:08 ` Arnaldo Carvalho de Melo
2016-02-02 15:52 ` Arnaldo Carvalho de Melo
2016-02-02 20:38 ` Arnaldo Carvalho de Melo [this message]
2016-02-03 2:06 ` Wangnan (F)
2016-02-03 7:09 ` Adrian Hunter
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=20160202203804.GH32488@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=wangnan0@huawei.co \
--cc=wangnan0@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 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.