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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 93880C433EF for ; Tue, 10 May 2022 21:07:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=x6ynADPA54AyB4vjLShN4jVtEx6vu7qe8ubPSPsVqd8=; b=pmjfxte6UzeI6p stqS9e/BXS3P95DQXZQ2Kgks+HWy7auc5+GhemoB6myCzB78OCn0twql1taeyAt+TxC2pY0qwHq6l Bf9LOjXFGgN+CAlcCa8ImIGqds2YFQYgU2UO8hFN5FGZKvg5aD9JXW7Ykb8ZYZM32tNWq3ZoHy8CH mAkuRUq8Ox8wAyz59vruBEYFJw2ZoYlwA5Uil+3g0kxF5/fOvN/VSGsyxCqLC/Zbm5OJJxyDvC1PH +qr/J0E2HIq9H7dMugkO3wN6/QU+nE95AFtYE1lWcPtV9m9qIdyOgzg/Et/zjMt1fRojzZMpYuBqW taiZ+WixaTLHolpVqtyA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1noX3V-0043R9-LV; Tue, 10 May 2022 21:06:05 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1noX3S-0043Q4-9K for linux-arm-kernel@lists.infradead.org; Tue, 10 May 2022 21:06:03 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A18612FC; Tue, 10 May 2022 14:06:01 -0700 (PDT) Received: from [10.57.80.111] (unknown [10.57.80.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 44E563F5A1; Tue, 10 May 2022 14:06:00 -0700 (PDT) Message-ID: <50489f55-c86c-48d2-1f4c-e6662349a043@arm.com> Date: Tue, 10 May 2022 22:05:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 0/4] perf/arm-cmn: Add CMN-650 and CMN-700 Content-Language: en-GB To: Qian Cai Cc: will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org References: <20220510171520.GA215@qian> <781f1ac8-a30c-81d9-8831-22bfbf593f58@arm.com> <20220510193815.GA302@qian> From: Robin Murphy In-Reply-To: <20220510193815.GA302@qian> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220510_140602_417854_AB90E80E X-CRM114-Status: GOOD ( 19.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-05-10 20:38, Qian Cai wrote: > On Tue, May 10, 2022 at 06:50:56PM +0100, Robin Murphy wrote: >> Hmm, can you narrow it down a bit more to a particular patch and/or a >> specific reproducer? I don't see how it could really be crashing >> dereferencing event->pmu, especially since none of the code this early in >> event_init has even changed recently :/ > > Right, there is an old bug that sometimes the debuginfo on kernel > modules is not accurate on arm64, so gdb and faddr2line gave the wrong > line. Anyway, using the printk() method, we were faulted on this line. > > + /* This is sufficiently annoying to recalculate, so cache it */ > + hw->filter_sel = arm_cmn_filter_sel(cmn->model, type, eventid); Aha, that's a much more believable culprit - 0x38 also stood out as an offset in the attribute structures. > Also, it can be reproduced within 5-min by running, > > $ trinity -C 128 -cperf_event_open I can already guess what I've done, and just reproduced the crash directly on the first try :) I'll work on the fix tomorrow, thanks for the report and info! >> Something's definitely screwy here though... these ID numbers should have a >> device type above them. Was this dumped with patch #1 applied, and if not do >> they show as "????" when it is? > > Yes, with the series applied, we have, Ah, turns out I can no longer get away with being lazy and not masking the device_type field properly when reading connect_info, as some of the adjacent bits are no longer reserved since the debugfs code was first written - I've not played with a CAL config of any of the newer stuff, or I might have noticed sooner. But at least that tweak to differentiate unknown from unconnected has now paid for itself :D Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel