Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp29210909rwd; Wed, 5 Jul 2023 08:39:26 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4gs4WO+jYhwQAcTUwbaUqLh75p+ATgIlkT9hJeXhGzbU4ArRLNsg/UnZIgYlFtdEaEHjt6 X-Received: by 2002:a54:4081:0:b0:3a3:6d2a:5c4a with SMTP id i1-20020a544081000000b003a36d2a5c4amr14673661oii.35.1688571566454; Wed, 05 Jul 2023 08:39:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688571566; cv=none; d=google.com; s=arc-20160816; b=E6WG3bwdYzwqB60Mv+l9AnZmf/dtoD87Gm3l7Y2D/ytQjfIbxfxjI4oXefqhJm/VcX PEE/5nawDjDmZnj3o617hEDdATITYOhFl/lq19e3zL4DcBEDMBo+ygBRIQ1VVI96ETxB nWwyyNYKsiSbWT5XekyZTSSTMPr7u+aRiC3btE0wWlMx7Kt8dLlzw4zCG5Q+JInspk2S dBEthLTHnv0s9B9eo+ItT45FI042pl8WZXJn+nS8BIK6UURds4rXr9uQ/SR7HjUX86dC zE/IrhlJV5twabwvyD3mDWdGF3XbaWFY47oDHZq62l+/LgxYV4949fykNB6kVKc7RijG nsVg== 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=/VJGOGJqHvFjeW0qL6Odln5/A8NPS5xcK3pZpae27P8=; fh=kBUQREVBcooDQBuL2nkigKuK7eaab30iDiIL/GRVJEg=; b=YhSDb3sSOSfr5ewLzO9d8o+YEwpyT6jd2wJ3SxwaR6z4o/lAO5letAHeVGf9d/XBDI iiGUxVXm6SeyHgv9lD5fOLGcVXP+weGYXhzFuN88qE5PgsuHrTcYFXv+bS+DTpDC54OY STbteyrC+fhQ9zCWgIBfhQbe+2ymQl5RVBWhSjM9l6fC77zr1DnPTdsX9z+L1rNL/Z5z 7OeN69sdBop1TCeCvX69U2rVHTGCAgJXf7BzWthl/uyiWIrkSIVpfLBYJdfw+ntyqi0F bGCriOpMyWJwaqNaBQn6lfF6ckkPF2GvBrDgP2FzT9Ttc9lOzvDWR6YwdT7Avymajks7 GvdQ== 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 o33-20020a634e61000000b00542aa78ebdasi22432059pgl.838.2023.07.05.08.39.10; Wed, 05 Jul 2023 08:39:26 -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 S233141AbjGEPMI convert rfc822-to-8bit (ORCPT + 99 others); Wed, 5 Jul 2023 11:12:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233134AbjGEPMH (ORCPT ); Wed, 5 Jul 2023 11:12:07 -0400 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32F50E59; Wed, 5 Jul 2023 08:12:06 -0700 (PDT) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-c5e76dfcc36so1807487276.2; Wed, 05 Jul 2023 08:12:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688569925; x=1691161925; 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=62I6/PnQSulzyBx7w8Sw+H+PkZ97zLVznFWaYHXFZXA=; b=KMOHA+88qszW2ryr5O1Bu8mJ0XcRxbXvJhZDK7DHAceH0Cn0U3EPhcZA+kD00Fa29T EmWDErzwIsE34uqTX+Hct81uQVFJAyUXclfhGB5Gv7SCjKh/K7hkkmDkj7DFcUS6akhP D5pJjpgU7XFvNwrvMqGLmy5bcAgVsSpvA8GE8IyXmWgIqEWrotSB2dm9eKAUj9rwWxIY qSuAHiHf/iK1TOXXzHtns5IX8aFM1BVu9g6tGDSicwwTYklmC685s5EYDUtymN447imj SieDDDYQK4sTwKMxxVZBCwH868Fc1sSIVa84+M22XvPtE/dkCumhp96/NdkoO0n+YFhV JSsQ== X-Gm-Message-State: ABy/qLZI6ptVybSgKthuwYJbwFRvHgsMBNoEk7Vx3dbQzWpZTftFBlDt rEg+LOOS9IPvDiaGd1kYmgOGDzU8v+f6Kn2Pu74= X-Received: by 2002:a25:154:0:b0:c62:9810:db26 with SMTP id 81-20020a250154000000b00c629810db26mr1976858ybb.26.1688569924873; Wed, 05 Jul 2023 08:12:04 -0700 (PDT) MIME-Version: 1.0 References: <20230704181516.3293665-1-namhyung@kernel.org> <20230705083833.GE462772@hirez.programming.kicks-ass.net> In-Reply-To: <20230705083833.GE462772@hirez.programming.kicks-ass.net> From: Namhyung Kim Date: Wed, 5 Jul 2023 08:11:53 -0700 Message-ID: Subject: Re: [PATCH] perf/x86: Fix lockdep warning in for_each_sibling_event() on SPR To: Peter Zijlstra Cc: Ingo Molnar , Mark Rutland , Alexander Shishkin , Arnaldo Carvalho de Melo , LKML , Kan Liang , Stephane Eranian , Greg Thelen , stable@vger.kernel.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 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 Hi Peter, On Wed, Jul 5, 2023 at 1:38 AM Peter Zijlstra wrote: > > On Tue, Jul 04, 2023 at 11:15:15AM -0700, Namhyung Kim wrote: > > On SPR, the load latency event needs an auxiliary event in the same > > group to work properly. There's a check in intel_pmu_hw_config() > > for this to iterate sibling events and find a mem-loads-aux event. > > > > The for_each_sibling_event() has a lockdep assert to make sure if it > > disabled hardirq or hold leader->ctx->mutex. This works well if the > > given event has a separate leader event since perf_try_init_event() > > grabs the leader->ctx->mutex to protect the sibling list. But it can > > cause a problem when the event itself is a leader since the event is > > not initialized yet and there's no ctx for the event. > > > > Actually I got a lockdep warning when I run the below command on SPR, > > but I guess it could be a NULL pointer dereference. > > > > $ perf record -d -e cpu/mem-loads/uP true > > > > The code path to the warning is: > > > > sys_perf_event_open() > > perf_event_alloc() > > perf_init_event() > > perf_try_init_event() > > x86_pmu_event_init() > > hsw_hw_config() > > intel_pmu_hw_config() > > for_each_sibling_event() > > lockdep_assert_event_ctx() > > > > We don't need for_each_sibling_event() when it's a standalone event. > > Let's return the error code directly. > > > > Fixes: f3c0eba28704 ("perf: Add a few assertions") > > Reported-by: Greg Thelen > > Cc: stable@vger.kernel.org > > Signed-off-by: Namhyung Kim > > --- > > arch/x86/events/intel/core.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c > > index 0d09245aa8df..933fe4894c32 100644 > > --- a/arch/x86/events/intel/core.c > > +++ b/arch/x86/events/intel/core.c > > @@ -3983,6 +3983,14 @@ static int intel_pmu_hw_config(struct perf_event *event) > > struct perf_event *leader = event->group_leader; > > struct perf_event *sibling = NULL; > > > > + /* > > + * The event is not fully initialized yet and no ctx is set > > + * for the event. Avoid for_each_sibling_event() since it > > + * has a lockdep assert with leader->ctx->mutex. > > + */ > > If I understand things correctly, your patch is indeed correct, however > I don't much like this comment, does something like: > > /* > * When this memload event is also the first event (no > * group exists yet), then there is no aux event before > * it. > */ > > work for you? Yep, looks good. Do you want me to resend? Thanks, Namhyung > > > + if (leader == event) > > + return -ENODATA; > > + > > if (!is_mem_loads_aux_event(leader)) { > > for_each_sibling_event(sibling, leader) { > > if (is_mem_loads_aux_event(sibling)) > > -- > > 2.41.0.255.g8b1d071c50-goog > >