Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp346887pxb; Wed, 29 Sep 2021 00:06:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0/Isl2xnpxmkFRWsK3Qb7DzpmDCzQDU7c4gZFwhxR1kD23Ob00n7piod+pZ00a2gd9NmK X-Received: by 2002:a17:902:e34b:b0:13e:4004:2e78 with SMTP id p11-20020a170902e34b00b0013e40042e78mr8711932plc.77.1632899201278; Wed, 29 Sep 2021 00:06:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632899201; cv=none; d=google.com; s=arc-20160816; b=N835HeDQmXGk404DBzkoUpz1J6ABfuAcyk4NKk9lM+dXoGRAvyPSW20viBJP3dGeFz B0Rz1gBhUA8/2c7ZLymb+w+cxXg5jFzqOkNrXqh/OK/Tm8ZFXD/I0/HiAXCopuoMrCsV qHzQFDVKxPXiLJF1lHbpTfxBeDI4YiteUEXOtDTU9R6qOSZeizzrFjCALNokUBq1M4PJ VfOSLlDJn3b+lZs+/h+9N9WlCltF3G+3VafCk1PIToF/PH74Z7UYFZr7la5BWRX4MlHN Z3rPDAboIbDR6A3FEw1p/Esx/i9xhMN544FecND88Je/x0RlT7CQhsGmGCJFApEDCPxS KnbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :dkim-signature; bh=485aqyMaDhgNS2O/IDjEvg+jxK02XiMi7beDqYxp0oU=; b=kg9S5zK1bOtLMzs+NK59U+iTcgDk93FDYWm34ohgGBoXMV7ehCIDQphDUOvdDV56Ru x4LLEqdelGX4l6aCeB9fzxb6MIGNplu5KitkYAUkiWaKIlm0GE87kf6sTAX04qeh6Q8k afvqf8QY4pFxjMbGCpE8n2QzM+M0vEjQfEGQNznxzNQ5MegojvdmKVlECwEO2j5t+sDc l7kPgcRkMkkIBOMcQb1Z/mamg2dorYJd1EGW5qy1H+jH0Yc7lkBVT6sTaFNkmKEvxahC YL0KjXxGTghIyxEq2o0AFmevTnv65AyOCxoYa5hpdikZSZ8vcgvItNp1rIS0HqU24bLs De0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pn51I8Fo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o1si1967901pfd.98.2021.09.29.00.06.23; Wed, 29 Sep 2021 00:06:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pn51I8Fo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244489AbhI2HGP (ORCPT + 99 others); Wed, 29 Sep 2021 03:06:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244488AbhI2HGO (ORCPT ); Wed, 29 Sep 2021 03:06:14 -0400 Received: from mail-qk1-x74a.google.com (mail-qk1-x74a.google.com [IPv6:2607:f8b0:4864:20::74a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AB8CC06161C for ; Wed, 29 Sep 2021 00:04:34 -0700 (PDT) Received: by mail-qk1-x74a.google.com with SMTP id j6-20020a05620a288600b0045e5d85ca17so7743799qkp.16 for ; Wed, 29 Sep 2021 00:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=485aqyMaDhgNS2O/IDjEvg+jxK02XiMi7beDqYxp0oU=; b=pn51I8FoCpp0r1PED2fZr8xnbRt/fFAtSye7wwHS3v5i7peflI0195y+mVTHkFdmsB xWM1nb/BQrYjDfZtCi1N79y0Ov8BNZsLNkLTCxd0q8qUr+HLUnGb4iKYmCZgmsZVpy9f 3Ab9kA3sTdmkF/RT516ifCN162EU88z1b5BxNP/wsRKvOYBYAhgXebURobTSNG3mFggG T3mfnkBSQMb9SBBsCcsnHkqjNP+vvmc665nRH3Vs7/rWZm9zi2Cksri2yDHW/gK/edoL KnozByn9nPtxgxgS2du9I31tptg0QWOAnr7ji5UwKsgw9/6GPHrSlxotgZEXvQh20Vbv IaYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=485aqyMaDhgNS2O/IDjEvg+jxK02XiMi7beDqYxp0oU=; b=OAjm7XVrhklUvHrUKsAZ3uTauKiM6PiTTpeaOjPVD1p+9FcVBEIu4ikgPGoprpcPPo w2cUS3PPxMIvBnt0865URqdiJQiEO+h5ci3EHAL1eFilK1Pavao6KW6mGO5R8QGrD+J/ n95jbZ+gwpTeSilblYa5RzHzNMEDFBOT3jjqW0po0phCyyEOKvSQVSWiGtJDowkdAxem 4+o0kIbKFEdi1CknrB5POV7veyG023eVmnYiS1bi036GQpQ69MMRNvR0Mnx5bY2kOr4F nbZxSQQ471eJsX3Xfj+OJvaxv4NuM4qChJKL+c6hzMZiegKcAO/YCoqocaq2V0jG9xXD /vHA== X-Gm-Message-State: AOAM533X2+VP1HdeLtiyW2eiBzx9Lgm/3cytcISY/Ceql6wHWCqqkAdh yvYWbPGNhTLNt47dADT66IwvaW4RIcsq X-Received: from nandos.syd.corp.google.com ([2401:fa00:9:14:846e:ae82:9f80:179b]) (user=amistry job=sendgmr) by 2002:a05:6214:17d1:: with SMTP id cu17mr10202777qvb.14.1632899073573; Wed, 29 Sep 2021 00:04:33 -0700 (PDT) Date: Wed, 29 Sep 2021 17:04:21 +1000 Message-Id: <20210929170405.1.I078b98ee7727f9ae9d6df8262bad7e325e40faf0@changeid> Mime-Version: 1.0 X-Mailer: git-send-email 2.33.0.800.g4c38ced690-goog Subject: [PATCH] perf/x86: Reset destroy callback on event init failure From: Anand K Mistry To: linux-perf-users@vger.kernel.org Cc: Anand K Mistry , Alexander Shishkin , Arnaldo Carvalho de Melo , Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org perf_init_event tries multiple init callbacks and does not reset the event state between tries. When x86_pmu_event_init runs, it unconditionally sets the destroy callback to hw_perf_event_destroy. On the next init attempt after x86_pmu_event_init, in perf_try_init_event, if the pmu's capabilities includes PERF_PMU_CAP_NO_EXCLUDE, the destroy callback will be run. However, if the next init didn't set the destroy callback, hw_perf_event_destroy will be run (since the callback wasn't reset). Looking at other pmu init functions, the common pattern is to only set the destroy callback on a successful init. Resetting the callback on failure tries to replicate that pattern. This was discovered after commit f11dd0d80555 ("perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op") when the second (and only second) run of the perf tool after a reboot results in 0 samples being generated. The extra run of hw_perf_event_destroy results in active_events having an extra decrement on each perf run. The second run has active_events == 0 and every subsequent run has active_events < 0. When active_events == 0, the NMI handler will early-out and not record any samples. Signed-off-by: Anand K Mistry --- arch/x86/events/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index e6db1a1f22d7..1f5d96ba4866 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -2284,6 +2284,7 @@ static int x86_pmu_event_init(struct perf_event *event) if (err) { if (event->destroy) event->destroy(event); + event->destroy = NULL; } if (READ_ONCE(x86_pmu.attr_rdpmc) && -- 2.33.0.800.g4c38ced690-goog