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 A3BCFCAC587 for ; Tue, 9 Sep 2025 15:43:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eslyvRzrOaO/NFd8kJX9XJrenNYmFG93rUkI5O6NmHc=; b=YWGIL3Twt76JTFwX+iAHThZCSg U/BFjSSDn35dlhH7H0bT7zQ1MvOWgBJPDQSjRMosu+7eR7TgoxOE4873LYy91KrOcBRMrwFl0mqmI 3aprCsPX2ZPsyrB8d7EeN4Yii2RWHJpC24aTpEAAxIKfXiQWjtrI9tmzx4ZDug6cFZBiW6bVL/31X IUsowEOLkROW6CXcBPkHLOIj3PJdJfiv9HvQNfz9LOl0ba5WDufD4ETEScTe4XArfeErHmH9+NZ4Y gJLJWtLN2cnepEyfaREhJtsJBujgBdmJwQSv53Kb5Ch8LZJj7KSrJ/i+NNVdg9h1PK3i9JyI5At8q ci8s83Sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uw0Ur-00000008DDF-0dMg; Tue, 09 Sep 2025 15:43:05 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uvvNk-00000006J5u-33LT for linux-arm-kernel@lists.infradead.org; Tue, 09 Sep 2025 10:15:25 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6D0F9406EC; Tue, 9 Sep 2025 10:15:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1ACBC4CEF4; Tue, 9 Sep 2025 10:15:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757412924; bh=W4ZNNxvoHzwG3XR6SRFoMRWquFrLJc9azWmuVkfqFbk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P/BUqdfDHVAiCMuZDphbqs1NG9VJi7db+t8nkDQz3QVKv0Dfm/UmlSNu8SkGceqrL 4DNtHy3sIm01JuUR6VxzRG14wg36xFHUCeYafD/CVf1PLWLLMlZF6cucspP9kpZu2i JnXwA5Nz4XHdp7BrcMhA3wBX3wD7Whna8PQb6OX66SgkhomCdMHQWULD6elxq6q8mU SXRBYjMqw9PuBx3Y5TaGqDoUHCODQJFFvHvhw4NAoP6YhGpoVe9DFT4cUTwoAGp/3Q bP7SNzyUVyQBg/AK5BlzTodr/etp4Q6Du6UgzhFQt67cSknW9nVs7dtBksmjAOdKO+ RR5JoZ8/i8pjA== Date: Tue, 9 Sep 2025 11:15:19 +0100 From: Will Deacon To: Krzysztof Kozlowski Cc: Mostafa Saleh , linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org, alim.akhtar@samsung.com, Peter Griffin , =?iso-8859-1?Q?Andr=E9?= Draszik Subject: Re: [PATCH] soc: samsung: exynos-pmu: Fix for CONFIG_DEBUG_PREEMPT Message-ID: References: <20250905162446.88987-1-smostafa@google.com> <19a6f296-eb40-49cf-9571-2d7964cd3313@kernel.org> <84332e77-cfd2-4090-a3c0-114a9eb5422a@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84332e77-cfd2-4090-a3c0-114a9eb5422a@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250909_031524_826341_9C2C7C50 X-CRM114-Status: GOOD ( 22.77 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Krzysztof, On Sat, Sep 06, 2025 at 09:07:02AM +0200, Krzysztof Kozlowski wrote: > On 05/09/2025 19:43, Mostafa Saleh wrote: > >>> > >>> As this value is only read once, it doesn't require to be stable, so > >> > >> Why it does not need to be stable? Onlining wrong CPU number is not > >> desired... > >> > >>> just use "raw_smp_processor_id" instead. > >> > >> You might be just hiding some other real issue, because above stacktrace > >> is from gs101_cpuhp_pmu_online() which IRQs disabled and preemption > >> disabled. Provide analysis of the warning, instead of just making it > >> disappear. > > > > Not sure I understand, how is preemption disabled? that wouldn't fire > > in that case. > > Because there is explicit preempt_disable(). Where do you see that? >From what I can tell, the driver (somewhat bizarrely) registers its online callback much earlier (at CPUHP_BP_PREPARE_DYN) than the offline callback so that gs101_cpuhp_pmu_online() will be run in the context of the caller/onliner rather than the actual CPU coming up. I don't see anything which disables preemption on that path. > So far you did not present any code analysis, any actual arguments, so > deflecting reviewer's comment like above will get you nowhere. Instead > of replying with a question, bring arguments that the code path does not > disable the preemption. Mostafa's reported a bug and had a go at fixing it, for goodness sake. Would you rather not hear about bugs in the code you maintain? As somebody who should understand this code better than most, perhaps you could try a bit harder to fill in the blanks on the technical side rather than pointing out extraneous blank lines and making questionable judgements about CC lines. > My call is that you run all this on some other kernel, just like usually > happens in Google. Whilst that inevitably happens with some of the more product-facing teams, I think it's foolish to assume that nobody works directly with upstream at Google. We're also not going to waste time fabricating bug reports which is why we bother to reproduce issues on Pixel 6, as that can boot upstream without any additional patches. Will