Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp19739333rwd; Wed, 28 Jun 2023 13:35:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5OfGMKzhD6jfqQxtvNM9R4Q9no+QK6vN7ZU+YUYQoFXBrrRL6simGR3sTrrcucZe35gg6j X-Received: by 2002:a17:902:a40f:b0:1b5:b28:2ff1 with SMTP id p15-20020a170902a40f00b001b50b282ff1mr2649989plq.10.1687984553714; Wed, 28 Jun 2023 13:35:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687984553; cv=none; d=google.com; s=arc-20160816; b=lqMDQCtfEHGnNYPB8Fcmvki/u1jzPXsl2WwL0AYrUkHAxdy3wKU4/62xXGlPtgkcVe akYJA86wUTjjB2hFruDYBGm4958llqAfP/Hh7R2kRsWO81CA2VZEFAru9OtLnblUIVJD 3DVyXyN5ovvXhkVWtxLuFS2Pc4z2zh6qiBjMG+YIm+c5KYOB00Ysvy7sGEYmtaWgMtXS Wah7ecBPMWWnyhPbyAa6GO4s3dilZxCMOroqjswETCxjoLnigO3AU/HTotpTxkEON962 1Xp3gwfmx6m09cMV0/Qzu3Y+DAXwH+QZPKdjRXwCzkFp4+LWwDR3K/ityiVhovk6i2bz Qygg== 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=cPa2ZQSs59/lZmARrh931w3+uiOYObXlHmX6Z3pjMRk=; fh=YYiimnHBh2/aMw0c2UAM9IkNO/ixI1zyh1xvd9QmSkM=; b=dJ6uXUgwSUpzv8LNvCUDhjcrmKFGnG/ITO29lW0AdI6rxGBxuKBHf3Ox2IhOJe1Y8J Xu8vm1vKvW8GLFKhM/PhMPOwCNWASOqT39AmETdIQfMdFNI7WtDZhp/MKJP3DVW8aoT4 4XH3cqwJzhoDu39h44GqMSvDTXp0b6Qg3/sa9J4sLIQhE3EVNS0Zp22uF+PCAkBUKhhy rJ9WoXFMoNOibDr9XqBu87pTAmY+kIQyaWkhv7HX+/GLhXuuZ30rRBeQmvbi+C6S6Zn5 W5Bk3pvFVREt+RbQVRyf92zNSOWlxeXriU2U/KGDZxXkMDXSCaAEnZRCXqagXr2UyCvs O0JA== 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 h7-20020a63df47000000b0055387a0517dsi9516416pgj.529.2023.06.28.13.35.41; Wed, 28 Jun 2023 13:35:53 -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 S231830AbjF1UGt convert rfc822-to-8bit (ORCPT + 99 others); Wed, 28 Jun 2023 16:06:49 -0400 Received: from mail-yb1-f178.google.com ([209.85.219.178]:42493 "EHLO mail-yb1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230060AbjF1UGr (ORCPT ); Wed, 28 Jun 2023 16:06:47 -0400 Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-bad0c4f6f50so467378276.1; Wed, 28 Jun 2023 13:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687982806; x=1690574806; 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=2cyNi1a1Nb17nGMmnPDS7fjF0SkMOGKhIkklLddywOk=; b=X1x3rNuF6XKQM6/TLqTi3ipiO1ZLqjPjNRj2C8BwtBQ9XNJmI22JIqN+1Wh3h6zUGO 5uje30xDoxF6H1SPjJFM6KNfzUi500bXZ/WRGCxNetICCr4MZgZiLeooIcvROorTuaNU o4uD5qsT+G2RLeOKLJIl1SfqFb7QRLY2xHMUkJo09d8ibgHc+hRu1Uc8lk4AHVcZXZJz N7yT/JfveCUBvfqkc7Vs8H+gijmD4mMeFi6iSF2e3igJGZdKgeKh0IkGMIb608bsIAkt 2DvM09yxN9h60srKylUXxPjASeE6JjDj02yts5xGZWK3GJpVIoE/UusMWXmspa2JmGxL xweA== X-Gm-Message-State: ABy/qLYUipwWaIQOpzorcv4/nzVOqpICmA4JvLewwSNCrdpYSDsGFuRY KK397THGK79NpO7s+FCxtKRywJP1dhj80sdkjps= X-Received: by 2002:a25:553:0:b0:bc8:42db:2c07 with SMTP id 80-20020a250553000000b00bc842db2c07mr2388631ybf.25.1687982806236; Wed, 28 Jun 2023 13:06:46 -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: Wed, 28 Jun 2023 13:06:35 -0700 Message-ID: Subject: Re: [PATCH 2/2] perf report: Don't add to histogram when there is no thread found To: James Clark Cc: Ian Rogers , 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 28, 2023 at 3:34 AM James Clark wrote: > > > > On 27/06/2023 18:19, Ian Rogers wrote: > > On Tue, Jun 27, 2023 at 9:58 AM Namhyung Kim wrote: > >> > >> 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? > > > > Yep: > > Acked-by: Ian Rogers > > Looks good to me too. Should I resend the set with this change instead > of my one? No, I can take care of that. I'll take this as your Acked-by. :) Thanks, Namhyung