Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp5805759ybx; Sun, 10 Nov 2019 22:04:47 -0800 (PST) X-Google-Smtp-Source: APXvYqzYLSQJQBZqdaQ4h0B/38g36obUkURo+8HykEgcEg3+g0rNDQVjLAWD+QkdaGewbJO10vRh X-Received: by 2002:a17:906:f255:: with SMTP id gy21mr21430054ejb.204.1573452287371; Sun, 10 Nov 2019 22:04:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573452287; cv=none; d=google.com; s=arc-20160816; b=hB1A09v4CMAl3WUTAmgvl9NL8XdnEUOegkgOa3OxQgAWRl4jRUoyEGx/XGt2h66fHT 362QBn145h35X4qZPLRjgpBWkPsRG+SX8qLtqM2WWuA9nX3LSOPWI2XqHZOLjn1KzTUf piUB+ULiBBplAWjdtGZC0/4JVMEfc684Ezz5p0Jm3TlcFbAWfp8iYBlI7dbVT2oyuYcz ce6y/bSk2bdkwu4+Y10+CARGIAU47XeyIYXz/kWb2B+A8XRduy66GRQTiViRLCBsYCt3 YivdMsRXfSSNrghyaRFdLiC7u4LMDSAXq/ibvd4UaaXitkR8uwdHGUy/ydNfAuob4XMP OXUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=JKrMYAHXbOmJwoFV0V1xu7AODz4NKznHhaHh6opIL9w=; b=LM8361xYQB/W9EtbHSlhnXLo1HvSzg7Xy7tclTC4NrBkUejhWKS0vSe+yIyrjc92fP H5EBwRi3N/XSyt5P23YkOzuV7h4r4Wvr0dEf2QwtxxQZkpwFACYxyBpU6+LCzuCNNKjL 5Jwx8/hw6lavb1UN5gxZzVVe3o0Qgvt6qQ2BqNw96Cs0s53GXox32A8PIQRNq7PbaF8q G0+4Qrat93H3wEltzfhU337ekND/B/vPdP9pAfHJlSHQb0L2RN1wX1y1v7gF2qD10Uj4 EaUsTMwRJbBeHJGkaFSZquZmt/jTxPm5F+hHDE6OtRCB27qgAZM/tiBj4Ch2+/0iJdXu Y5rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WlVHQzIJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a18si3381915ejj.100.2019.11.10.22.04.23; Sun, 10 Nov 2019 22:04:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WlVHQzIJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726955AbfKKGBg (ORCPT + 99 others); Mon, 11 Nov 2019 01:01:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:46760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbfKKGBg (ORCPT ); Mon, 11 Nov 2019 01:01:36 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6D88320656; Mon, 11 Nov 2019 06:01:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573452094; bh=r2/46Oo7bzlP9QELn0pm6e6LdiAFm+dgs0+pcUxGDOQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WlVHQzIJM20xcbXlcK1Ol8oaCuqcHpKxgfD4GWSGZ890mzTBiDyJocMWMK/aajIoH zFEHtHcOpa+qWbMSIWCY1uyqCuFSyrpbnu15vhkyvsKgfLDNJC3dtC1zA6XlkMTyNi wFW4EpAhLRmhgJW/gN20IziDGpQejHQXTUTHFvMI= Date: Mon, 11 Nov 2019 07:01:29 +0100 From: Greg Kroah-Hartman To: Andres Freund Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, John Keeping , Jiri Olsa , Alexander Shishkin , Konstantin Khlebnikov , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: Re: [PATCH 5.3 111/344] perf unwind: Fix libunwind when tid != pid Message-ID: <20191111060129.GA3197363@kroah.com> References: <20191003154540.062170222@linuxfoundation.org> <20191003154551.163214533@linuxfoundation.org> <20191110014621.n5yfednqfl7g3atr@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191110014621.n5yfednqfl7g3atr@alap3.anarazel.de> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 09, 2019 at 05:46:21PM -0800, Andres Freund wrote: > Hi, > > On 2019-10-03 17:51:16 +0200, Greg Kroah-Hartman wrote: > > From: John Keeping > > > > [ Upstream commit e8ba2906f6b9054102ad035ac9cafad9d4168589 ] > > > > Commit e5adfc3e7e77 ("perf map: Synthesize maps only for thread group > > leader") changed the recording side so that we no longer get mmap events > > for threads other than the thread group leader (when synthesising these > > events for threads which exist before perf is started). > > > > When a file recorded after this change is loaded, the lack of mmap > > records mean that unwinding is not set up for any other threads. > > > > This can be seen in a simple record/report scenario: > > > > perf record --call-graph=dwarf -t $TID > > perf report > > > > If $TID is a process ID then the report will show call graphs, but if > > $TID is a secondary thread the output is as if --call-graph=none was > > specified. > > > > Following the rationale in that commit, move the libunwind fields into > > struct map_groups and update the libunwind functions to take this > > instead of the struct thread. This is only required for > > unwind__finish_access which must now be called from map_groups__delete > > and the others are changed for symmetry. > > > > Note that unwind__get_entries keeps the thread argument since it is > > required for symbol lookup and the libdw unwind provider uses the thread > > ID. > > > > Signed-off-by: John Keeping > > Reviewed-by: Jiri Olsa > > Cc: Alexander Shishkin > > Cc: Konstantin Khlebnikov > > Cc: Namhyung Kim > > Cc: Peter Zijlstra > > Fixes: e5adfc3e7e77 ("perf map: Synthesize maps only for thread group leader") > > Link: http://lkml.kernel.org/r/20190815100146.28842-2-john@metanate.com > > Signed-off-by: Arnaldo Carvalho de Melo > > Signed-off-by: Sasha Levin > > This unfortunately broke --call-graph dwarf on 5.3 (and presumably older > branches), because while this commit has been included in stable, the > prerequisite > > commit ab6cd0e5276e24403751e0b3b8ed807738a8571f > Author: John Keeping > AuthorDate: 2019-08-15 11:01:44 +0100 > Commit: Arnaldo Carvalho de Melo > CommitDate: 2019-08-16 12:25:23 -0300 > > perf map: Use zalloc for map_groups > > In the next commit we will add new fields to map_groups and we need > these to be null if no value is assigned. The simplest way to achieve > this is to request zeroed memory from the allocator. > > Signed-off-by: John Keeping > Reviewed-by: Jiri Olsa > Cc: Alexander Shishkin > Cc: Konstantin Khlebnikov > Cc: Namhyung Kim > Cc: Peter Zijlstra > Cc: john keeping > Link: http://lkml.kernel.org/r/20190815100146.28842-1-john@metanate.com > Signed-off-by: Arnaldo Carvalho de Melo > > has not. > > > The crash I get is: > > Thread 1 "perf" received signal SIGSEGV, Segmentation fault. > 0x0000555555872238 in unwind__flush_access (mg=0x555555c53b50) at util/unwind-libunwind.c:76 > 76 mg->unwind_libunwind_ops->flush_access(mg); > (gdb) bt > #0 0x0000555555872238 in unwind__flush_access (mg=0x555555c53b50) at util/unwind-libunwind.c:76 > #1 0x0000555555800ac4 in ____thread__set_comm (exec=true, timestamp=325096707055731, str=0x7ffff7f96ed8 "sleep", thread=0x555555c53bc0) at util/thread.c:254 > #2 __thread__set_comm (thread=thread@entry=0x555555c53bc0, str=str@entry=0x7ffff7f96ed8 "sleep", timestamp=325096707055731, exec=exec@entry=true) > at util/thread.c:268 > #3 0x00005555557f132a in machine__process_comm_event (machine=0x555555c4bc68, event=0x7ffff7f96ec8, sample=0x7fffffff8f70) at util/machine.c:600 > #4 0x00005555557fa93b in perf_session__deliver_event (session=0x555555c4baf0, event=0x7ffff7f96ec8, tool=0x555555acb9a0 , file_offset=73416) > at util/session.c:1473 > #5 0x00005555557feae8 in do_flush (show_progress=true, oe=0x555555c52610) at util/ordered-events.c:243 > #6 __ordered_events__flush (oe=oe@entry=0x555555c52610, how=how@entry=OE_FLUSH__FINAL, timestamp=timestamp@entry=0) at util/ordered-events.c:322 > #7 0x00005555557fef45 in __ordered_events__flush (timestamp=, how=, oe=) at util/ordered-events.c:338 > #8 ordered_events__flush (how=OE_FLUSH__FINAL, oe=0x555555c52610) at util/ordered-events.c:340 > #9 ordered_events__flush (oe=oe@entry=0x555555c52610, how=how@entry=OE_FLUSH__FINAL) at util/ordered-events.c:338 > #10 0x00005555557fd17c in __perf_session__process_events (session=0x555555c4baf0) at util/session.c:2152 > #11 perf_session__process_events (session=session@entry=0x555555c4baf0) at util/session.c:2181 > #12 0x0000555555729379 in process_buildids (rec=0x555555acb9a0 ) at builtin-record.c:829 > #13 record__finish_output (rec=0x555555acb9a0 ) at builtin-record.c:1037 > #14 0x000055555572c000 in __cmd_record (rec=0x555555acb9a0 , argv=, argc=2) at builtin-record.c:1661 > #15 cmd_record (argc=2, argv=) at builtin-record.c:2450 > #16 0x000055555579cd9d in run_builtin (p=0x555555ad4958 , argc=5, argv=0x7fffffffdcc0) at perf.c:304 > #17 0x0000555555714baa in handle_internal_command (argv=0x7fffffffdcc0, argc=5) at perf.c:356 > #18 run_argv (argcp=, argv=) at perf.c:400 > #19 main (argc=5, argv=0x7fffffffdcc0) at perf.c:525 > > (gdb) p *mg > $7 = {maps = {entries = {rb_node = 0x0}, names = {rb_node = 0x0}, lock = {lock = pthread_rwlock_t = {Status = Not acquired, Shared = No, > Prefers = Readers}}}, machine = 0x555555c4bc68, refcnt = {refs = {counter = 1}}, addr_space = 0x693f6967632e6775, > unwind_libunwind_ops = 0xa32313438313d64} > > (gdb) p mg->unwind_libunwind_ops > $8 = (struct unwind_libunwind_ops *) 0xa32313438313d64 > > (gdb) p *mg->unwind_libunwind_ops > Cannot access memory at address 0xa32313438313d64 > > which makes sense, because map_groups__new() allocates the group with > malloc, and map_groups__init() only initializes map_groups->{maps,machine,refcnt} > > > A bit surprised that nobody complained about this so far... Thanks, I've queued up the other patch for 5.3.y now. greg k-h