Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp10824023rwl; Mon, 2 Jan 2023 08:43:22 -0800 (PST) X-Google-Smtp-Source: AMrXdXu7IC67bPfhF5F/25WROtcPlBm0DfHvicCijzyQAqeeSQ+aSirDLJdhVeH+w17Gr6nnhPTN X-Received: by 2002:a17:907:3907:b0:840:db38:bf23 with SMTP id so7-20020a170907390700b00840db38bf23mr32432380ejc.26.1672677802706; Mon, 02 Jan 2023 08:43:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672677802; cv=none; d=google.com; s=arc-20160816; b=iNwDmq6tRclH/F08+hHAlVRNfa/F8OnKCmrxHXTXYHJ+EaYDeOLrR7ENZQBZIDSrgz sr7lRKG/gsl2j2Oldcp6CnW4FUAmmaTkn+ubPAs4n5A5hxzpusVDdpvkPokBTNDqra7I bJIauZ5eenz5PVaBgmlYFtilP+dTf4WYlqlujuBI1mrn6Evta1bRXrnHZisoN5z79PoU 35OPPCS8sSPTp3q5hR+E2J428Tt48CtlITHYLQLp2NuPxjmO5tkOBpvgUvd6g6Y4hwRX 3H9eeTFx869jQ1l7gDbaeIzD8ZZnqu8S9eIfH4eZPfF93qyiODq/wxfx4EJGuexcOLR9 rAXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=cORRp0gqn/d4DYRF5yGvw/ojf8urfV5NufyxQ/U6G8o=; b=VtFAdoKYgbBwG2F0ZvRk7rV5HFm+a8EWxrWITtjls/9hXQj2IzkZqtvYDTpZH7J8A/ T9rrUe25a6rhikFylrdwDtfFWpOFj00GFueAaN8zC0qKcq3tCwM0jJBFath7fk78R+T7 wdUWbJV/LCG/AvonasiJM1BivD8CTxA+MPmWdpYn17Hn3EhaXw1YqtLmJKK2pvsimS/V D+3cJZ4UCOmiFLYEgneLbdHIykSjZl73o7EpIvtz1ZHLSLqLNgfUavxV9QHp6eZlf/ZN HO/5436mdb8IdHJblNmiUeAdPpoVFfVbSFBZz867N8NP+hEd9Pe8S8q10+VwOcyegDop 19Lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=So9KnVLK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nb24-20020a1709071c9800b007c0dcc79ec5si29239896ejc.161.2023.01.02.08.43.08; Mon, 02 Jan 2023 08:43:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=So9KnVLK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236081AbjABPdr (ORCPT + 61 others); Mon, 2 Jan 2023 10:33:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236328AbjABPdk (ORCPT ); Mon, 2 Jan 2023 10:33:40 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B87A39FE6; Mon, 2 Jan 2023 07:33:39 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 546B260C2A; Mon, 2 Jan 2023 15:33:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D47FC433EF; Mon, 2 Jan 2023 15:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672673618; bh=5pca/j7McOj+rsY0jP+gJ5eTrXjI71iO+uCVP0GTu/s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=So9KnVLK934hERY7amnug0/GLUWW74/J8OGHgxmbVmPGXQk/onUsL0SqXereLtRC5 YBCSulVwb+HsdkCKIk2goAc05bBrxq7u8e9CNLW4NQ1n2K8/VOLCK74QY9TEcHYg7/ tBYqUMCA+tJnTV7Zt6/lgwTjJvCCA6IjFn2AVO85Wl+Ud4n+ab8a9rQKnGClEhzz37 QBXEDi3Vuy5oVTUrR4rDYOik3HFjMlCP87Yl2e267QqKYIhXWhzqT5TGH5uI8AkH8c Xpsr2Gh14ISo+7MZ2HVuWJTF9/oNlSrnr1YrUrF9emS0f3Z1rH5pH4RbXZKEobvFQr nOYQXyjC7pAhw== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 6EBE340468; Mon, 2 Jan 2023 12:33:35 -0300 (-03) Date: Mon, 2 Jan 2023 12:33:35 -0300 From: Arnaldo Carvalho de Melo To: Thomas Richter , Namhyung Kim Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, svens@linux.ibm.com, gor@linux.ibm.com, sumanthk@linux.ibm.com, hca@linux.ibm.com Subject: Re: [PATCH] perf lock: Fix core dump in command perf lock contention Message-ID: References: <20221230102627.2410847-1-tmricht@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221230102627.2410847-1-tmricht@linux.ibm.com> X-Url: http://acmel.wordpress.com X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, Dec 30, 2022 at 11:26:27AM +0100, Thomas Richter escreveu: > The test case perf lock contention dumps core on s390. Run the following > commands: > # ./perf lock record -- ./perf bench sched messaging > # Running 'sched/messaging' benchmark: > # 20 sender and receiver processes per group > # 10 groups == 400 processes run > > Total time: 2.799 [sec] > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.073 MB perf.data (100 samples) ] > # > # ./perf lock contention > Segmentation fault (core dumped) > # > > The function call stack is lengthy, here are the top 5 functions: > # gdb ./perf core.24048 > GNU gdb (GDB) Fedora Linux 12.1-6.fc37 > Copyright (C) 2022 Free Software Foundation, Inc. > Core was generated by `./perf lock contention'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00000000011dd25c in machine__is_lock_function (machine=0x3029e28, > addr=1789230) at util/machine.c:3356 > 3356 machine->sched.text_end = kmap->unmap_ip(kmap, sym->start); > > (gdb) where > #0 0x00000000011dd25c in machine__is_lock_function (machine=0x3029e28,\ > addr=1789230) at util/machine.c:3356 > #1 0x000000000109f244 in callchain_id (evsel=0x30313e0,\ > sample=0x3ffea4f77d0) at builtin-lock.c:957 > #2 0x000000000109e094 in get_key_by_aggr_mode (key=0x3ffea4f7290,\ > addr=27758136, evsel=0x30313e0, sample=0x3ffea4f77d0) \ > at builtin-lock.c:586 > #3 0x000000000109f4d0 in report_lock_contention_begin_event \ > (evsel=0x30313e0, sample=0x3ffea4f77d0) > at builtin-lock.c:1004 > #4 0x00000000010a00ae in evsel__process_contention_begin \ > (evsel=0x30313e0, sample=0x3ffea4f77d0) > at builtin-lock.c:1254 > #5 0x00000000010a0e14 in process_sample_event (tool=0x3ffea4f8480, \ > event=0x3ff85601ef8, sample=0x3ffea4f77d0, > evsel=0x30313e0, machine=0x3029e28) at builtin-lock.c:1464 > sample=0x3ffea4f77d0, evsel=0x30313e0, machine=0x3029e28) \ > at util/session.c:1523 > ..... > > The issue is in function machine__is_lock_function() in file > ./util/machine.c lines 3355: > /* should not fail from here */ > sym = machine__find_kernel_symbol_by_name(machine, "__sched_text_end", > &kmap); > machine->sched.text_end = kmap->unmap_ip(kmap, sym->start) > > On s390 the symbol __sched_text_end is *NOT* in the symbol list and the > resulting pointer sym is set to NULL. The sym->start is then a NULL pointer > access and generates the core dump. > > The reason why __sched_text_end is not in the symbol list on s390 is > simple: > When the symbol list is created at perf start up with function calls > dso__load > +--> dso__load_vmlinux_path > +--> dso__load_vmlinux > +--> dso__load_sym > +--> dso__load_sym_internal (reads kernel symbols) > +--> symbols__fixup_end > +--> symbols__fixup_duplicate > > The issue is in function symbols__fixup_duplicate(). It deletes all > symbols with have the same address. On s390 > # nm -g ~/linux/vmlinux| fgrep c68390 > 0000000000c68390 T __cpuidle_text_start > 0000000000c68390 T __sched_text_end > # > two symbols have identical addresses and __sched_text_end is considered > duplicate (in ascending sort order) and removed from the symbol list. > Therefore it is missing and an invalid pointer reference occurs. > The code checks for symbol __sched_text_start and when it exists assumes > symbol __sched_text_end is also in the symbol table. However this is > not the case on s390. > > Same situation exists for symbol __lock_text_start: > 0000000000c68770 T __cpuidle_text_end > 0000000000c68770 T __lock_text_start > This symbol is also removed from the symbol table but used in function > machine__is_lock_function(). > > To fix this and keep duplicate symbols in the symbol table, set > symbol_conf.allow_aliases to true. This prevents the removal of duplicate > symbols in function symbols__fixup_duplicate(). > > Output After: > # ./perf lock contention > contended total wait max wait avg wait type caller > > 48 124.39 ms 123.99 ms 2.59 ms rwsem:W unlink_anon_vmas+0x24a > 47 83.68 ms 83.26 ms 1.78 ms rwsem:W free_pgtables+0x132 > 5 41.22 us 10.55 us 8.24 us rwsem:W free_pgtables+0x140 > 4 40.12 us 20.55 us 10.03 us rwsem:W copy_process+0x1ac8 > # > > Fixes: cc2367eebb0c ("machine: Adopt is_lock_function() from builtin-lock.c") Humm, is that really the cset that introduces the problem? It just moves things around, the cset that introduced the is_lock_function() function, that assumed that __sched_text_end was always available was: commit 0d2997f750d1de394231bc22768dab94a5b5db2f Author: Namhyung Kim Date: Wed Jun 15 09:32:22 2022 -0700 perf lock: Look up callchain for the contended locks --- Right? Namhyung? Can you spot any problem in enabling duplicates as a fix? - Arnaldo > Cc: Arnaldo Carvalho de Melo > Signed-off-by: Thomas Richter > --- > tools/perf/builtin-lock.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c > index 718b82bfcdff..506c2fe42d52 100644 > --- a/tools/perf/builtin-lock.c > +++ b/tools/perf/builtin-lock.c > @@ -1670,6 +1670,7 @@ static int __cmd_report(bool display_info) > > /* for lock function check */ > symbol_conf.sort_by_name = true; > + symbol_conf.allow_aliases = true; > symbol__init(&session->header.env); > > if (!data.is_pipe) { > @@ -1757,6 +1758,7 @@ static int __cmd_contention(int argc, const char **argv) > > /* for lock function check */ > symbol_conf.sort_by_name = true; > + symbol_conf.allow_aliases = true; > symbol__init(&session->header.env); > > if (use_bpf) { > -- > 2.38.1 -- - Arnaldo