Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp18007102rwd; Tue, 27 Jun 2023 10:14:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ755UMFkg3MAfQpyG5LrvS2U8Mq4+8Y+hHbj3SBlJ5rv459XTWNdmAUHHHbuDHJAKPfQF+k X-Received: by 2002:a17:906:9b84:b0:989:5aad:ebce with SMTP id dd4-20020a1709069b8400b009895aadebcemr21295628ejc.13.1687886068476; Tue, 27 Jun 2023 10:14:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687886068; cv=none; d=google.com; s=arc-20160816; b=09IuB/tOV9givdomW0oTO9Dhjxiqxz/MWCeXYUT5wrw67WeljoP8XUc6ccA8gnT3Ka 4vlsPamnLDcHsF4suMtMRqfloaTKnK5DXxFhg5bqZfpyUVYfKjNfKdgdJmZK2B4kprUl +HQocGecc/ic7vPebfbnoncFwencw9EBZFKCCUJmZ+m/XOzfvrEuRrj50eg686lRbG9Z Yn58v/LRG/sKRnzaGHXj8fUvyiCZImyBBvHyKms5iGE/3sqSAlXI+HyTfVj1z99CTrhO isl2hW3XYdaB4oNpjorJY7QDx+8B6jmtOdAxwiXcWp6rt9wemK0sArDfoDsbLEStcW+o IF8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=DPLE3IK+TeF2Ydyttx6kj2t0zOZhrp378KyBlTLZM5g=; fh=HKEZlvbs12WHBoog07hyCspofLiB5TtLafPiYwDQdOY=; b=f4AGw5pKJd0kGdkbfXRuzjQYoWCf8V2A+B+P88Uhs9zMN8DPgjEAT4G5zvdC30+5OS AX7utyhoTMZM/o90VRbA9JNGl7rfqRmolwb+LYiULVCN/cTCQwWbOzKVIfBCgnFs+8Bm FX6+ya6ukC8At5DclnVgdRcl1SuxU1zpZIjEDe7uuOw5m4q9zCRlDW4rr/IPB4NQVGm/ mg1Az93JpCSlW9ac7bF6a0gtZLVRlgd3RD8Zspj35CvzmrRBnPErTmzTEzLd5/Y/T92X EvWOg7QFL5PFEKX/2m+EY4iuCRDrk3nyTLf8ihwvCSSKdrigeTKOqR2u5MnsM/BsorjW j2kg== ARC-Authentication-Results: i=1; mx.google.com; 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 j12-20020a17090686cc00b00988c76f9d4bsi4144391ejy.347.2023.06.27.10.14.02; Tue, 27 Jun 2023 10:14:28 -0700 (PDT) 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; 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 S230361AbjF0Q6K convert rfc822-to-8bit (ORCPT + 99 others); Tue, 27 Jun 2023 12:58:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230271AbjF0Q6H (ORCPT ); Tue, 27 Jun 2023 12:58:07 -0400 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38A5D171A; Tue, 27 Jun 2023 09:58:01 -0700 (PDT) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-57023c9be80so48222027b3.3; Tue, 27 Jun 2023 09:58:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687885080; x=1690477080; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n6c/E6AXYzbisGWFmvmo6pUwZPWyqFohyT+yy2+nmio=; b=GkQZgEpZRcV93bTL8u8jjRrkbWUAOjbdW0uYb7vvEcA0RV9X42sDgtT4qo1zmJBVNo y5kMTtV4FBm+GrpOvR0JiPPyXlX2FPOQuVBMXaPJLnOcbyiogVvTGpaT999Vt994E4iQ BcKC8WrY9or+vKCe0QKKnBg4p/SR0ZgqruFKYGuxsgqB9XgKMEdzzaTv56Qj9UW2yleq Qns7fpWneCVGXH8K6CEF8GDBnsnkON7hzADrX2FjFCRKXjaD/ie1lSGFUeMXLKNQtoRZ U5txGKmhpz/4L1uRVCVigzpsCCUawyHCl/jJYzPLb/JCv+3eteHMLmKNmcOoTCbfwLU4 NgIw== X-Gm-Message-State: AC+VfDy0ksUY4NkqH/8QwChMNzyiYq/MCGfYbY+oxYiTkmLd84BWghQq jhVJUc6C0W59k80ewjZk2V7eMsbZBTo1shhDGxk= X-Received: by 2002:a25:8407:0:b0:c19:9ca6:d18 with SMTP id u7-20020a258407000000b00c199ca60d18mr7689380ybk.38.1687885080211; Tue, 27 Jun 2023 09:58:00 -0700 (PDT) MIME-Version: 1.0 References: <20230626161059.324046-1-james.clark@arm.com> <20230626161059.324046-3-james.clark@arm.com> In-Reply-To: From: Namhyung Kim Date: Tue, 27 Jun 2023 09:57:48 -0700 Message-ID: Subject: Re: [PATCH 2/2] perf report: Don't add to histogram when there is no thread found To: Ian Rogers Cc: James Clark , linux-perf-users@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , Suzuki K Poulose , Mike Leach , Leo Yan , John Garry , Will Deacon , linux-kernel@vger.kernel.org, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no 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 On Tue, Jun 27, 2023 at 9:43 AM Ian Rogers wrote: > > On Mon, Jun 26, 2023 at 5:02 PM Namhyung Kim wrote: > > > > On Mon, Jun 26, 2023 at 05:10:58PM +0100, James Clark wrote: > > > thread__find_map() chooses to exit without assigning a thread to the > > > addr_location in some scenarios, for example when there are samples from > > > a guest and perf_guest == false. This results in a segfault when adding > > > to the histogram because it uses unguarded accesses to the thread member > > > of the addr_location. > > > > Looking at the commit 0dd5041c9a0ea ("perf addr_location: Add > > init/exit/copy functions") that introduced the change, I'm not sure if > > it's the intend behavior. > > > > It might change maps and map, but not thread. Then I think no reason > > to not set the al->thread at the beginning. > > > > How about this? Ian? > > (I guess we can get rid of the duplicate 'al->map = NULL' part) > > It seemed strange that we were failing to find a map (the function's > purpose) but then populating the address_location. The change below > brings back that somewhat odd behavior. I'm okay with reverting to the > old behavior, clearly there were users relying on it. We should > probably also copy maps and not just thread, as that was the previous > behavior. Probably. But it used to support samples without maps and I think that's why it ignores the return value of thread__find_map(). So we can expect al.map is NULL and maybe fine to leave it for now. As machine__resolve() returns -1 if it gets no thread, we should set al.thread when it returns 0. Can I get your Acked-by? Thanks, Namhyung