From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9509C433FF for ; Wed, 14 Aug 2019 23:51:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 74F4D206C1 for ; Wed, 14 Aug 2019 23:51:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Uay3WxpN"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="G9Al7jqB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74F4D206C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:From:Subject:References:Mime-Version :Message-Id:In-Reply-To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zF5mXTOyq1hvCacnap0Qu1kCm2yJm7AAhwy0K0o/+y0=; b=Uay3WxpN5Xb62S 742Ucb2icFr6Es8tyHtt2ZyuqRGhXTw8XU2YwCkI1AikF9cbeITvDhpYtCia8S0fHqJ8ZmhAj1/SK bTT7s8+XJ8g2qKH9mCTFVQXCb7P3mqVAfUvomzDNYLZ6l/Fg9U+S2Uq7A76lPoYP96DEbgr5gyMIP qfqNdoze858V00VUtdXRAOoBp7YYCj9QpN5vV9yhZ2ikxTu/8As/dFfPTn+cBgMvY3c2XxYX+4xCY QCEuAD06Xu5Kywy+carCsdmC3HJ71RgO0oRVy6m3vUuIBXAY5/vrEZPdl1Ur9Tzadu9bYHupKSMMQ yqH2f3kuFm2et6d6nXFA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hy32q-0004lP-SB; Wed, 14 Aug 2019 23:51:08 +0000 Received: from mail-pg1-x54a.google.com ([2607:f8b0:4864:20::54a]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hy32n-0004l4-K0 for linux-arm-kernel@lists.infradead.org; Wed, 14 Aug 2019 23:51:07 +0000 Received: by mail-pg1-x54a.google.com with SMTP id l11so268403pgc.14 for ; Wed, 14 Aug 2019 16:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=mCCHjAlFO5vAUYuV0pCQwN/48vRzFq+YkLLf8FK8aNk=; b=G9Al7jqBBI41vvj+P2TFIYHmTeK4JuIVUzUNnvWpI/c+YcsaiX3h+JT3tdTS6X5Opc kAYlb9p4SKnw8DgbDCx+LpcimPK8C68h5/K+lVbuq0M7F5eIV6rfRL1xuz+j7G+ip6Vh RZMtWaJzLPg4FKl6BNENo618JCDxuHq2mGhmrlacvzf+eWFxRzzNdig1eCrg/blI1LJu 2x6x7SnN9RiUXFPycEY9XiEM1qkzYe59zFwUZRKYMIgedOLfg53VHus55qOkD4k9gyVD 8uXyBC8NzgfGeGFcrZmj15kI+1F7/cbAZweQBLvyQ+wDcsQG3KHaa7FCr1DGTNymyM3H C1tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=mCCHjAlFO5vAUYuV0pCQwN/48vRzFq+YkLLf8FK8aNk=; b=b76PWpmzh4QQ2aYssUOk2s4GerhGZwY0oC5SggbtTKDW36jpUHwt5XV0wCuLyTAqN0 cwRdEkk6VSzCJS/I+rduZTy0eI9aQ0gcNUZXzsszLmE9lTSBkFv8kWQ8qP9tMnYPZh6O uudMXnOv3PZXJw9ENOiEXg165mTP9qbaxsM2TYCx/2XS5N1nV51mVJ3YnQR5wR4oKyon oJKlPWlpPKGECO/soRAfxIz3mc+j/cGB0E/1lrvv/FpL9Sxi7RsulCPXrurbz8VEdUIg geLposAEo63sedjRASd50pevgOCQXAeO8w35w6++k0Zl+uLj+vJcb+nQLVu2QFFIpUsN fJJA== X-Gm-Message-State: APjAAAXOtMw+BE2WmoAKUVsDhr5Yt1UjZNX8lZC1nzuaY8eK7K63Ut+I FdbRg3b2J1VNICZhdmZcb5n5GmIlEg== X-Google-Smtp-Source: APXvYqwQ7ZXfkseheaq9a7yygbzrcKzjgwsKviofG2LNhIBKUnkwv4PaV9kndL49aji1M5iN0KAYlk6+lgk= X-Received: by 2002:a63:7709:: with SMTP id s9mr1334272pgc.296.1565826661481; Wed, 14 Aug 2019 16:51:01 -0700 (PDT) Date: Wed, 14 Aug 2019 16:50:58 -0700 In-Reply-To: Message-Id: <20190814235058.184204-1-yabinc@google.com> Mime-Version: 1.0 References: X-Mailer: git-send-email 2.23.0.rc1.153.gdeed80330f-goog Subject: Re: [PATCH v2] coresight: tmc-etr: Fix perf_data check. From: Yabin Cui To: Mathieu Poirier , Suzuki K Poulose , Alexander Shishkin X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190814_165105_685637_A8687F4D X-CRM114-Status: GOOD ( 12.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Yabin Cui , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org > Did you actually see the check fail or is this a theoretical thing? > I'm really perplex here has I have tested this scenario many times > without issues. > I have seen this warning in dmesg output, that's how I find the problem. > In CPU wide scenarios each perf event (one per CPU) is associated with > an event_data during the setup process. The event_data is the > etr_perf holding a reference to the perf ring buffer for that specific > event along with the etr_buf, regardless of who created the latter. Agree. > From there, when the event is installed on a CPU, the csdev for that > CPU is given a reference to the event_data of that event[1]. Before > going further notice how there is a per CPU csdev and event handle to > keep track of event specifics[2]. As such both (per CPU) csdev and > event handle carry the exact same reference to the etr_perf. > On my test device (Pixel 3), there is an ETM device on each cpu, but only one ETR device for the whole device. So there is only one instance of etr csdev in the kernel. If multiple cpus are scheduling on etm perf events at the same time, all of them are trying to set their event_data to the same etr csdev. And different perf events have different event_data. A warning situation is as below: cpu 0 schedule on event A (set etr csdev->perf_data to event_a.etr_perf) cpu 1 schedule on event B (set etr csdev->perf_data to event_b.etr_perf) cpu 1 schedule off event B (update buffer, does nothing since csdev->refcnt != 1) cpu 0 schedule off event A (update buffer, but etr csdev->perf_data check fail) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel