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 63E33C7EE24 for ; Mon, 15 May 2023 09:36:45 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PS9t19uLajmfwU3ZyS2J6+eC+WzBD9kgE+tPV+/317c=; b=px+B5TvXU7toOs 1b7nA27gcxr5k4hoGwbyKogpFdiRZI7Rvd55ZDdjNKWSkFtleOibMSFuFU7tJfzzxxS6MrOGX4sn2 EFEMvw0yTmmL8YrjEvGtOyVxuhWQ6A8uPvcFHbdERZBuleq5ShTT7Q8KJd6NQkYTVobYYm8DvfaW5 LeDyM5ifwxl/QT4jWq1u3zcZTtwDniVuPV2v/QouPgUgjWfTTvQxtTs0a+o/8sPx18gL1xHwdJY2U yH+q/k1332V6sgXtq1UWZsOARi9aLe7RoOCkwdCaVmfAZjEqsmn6c11zEaq1Mx5s77wLZB4cjqclO QCkIwy0MRZHCKgJaGp6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyUcu-001a8U-33; Mon, 15 May 2023 09:36:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyUcr-001a5q-2U for linux-arm-kernel@lists.infradead.org; Mon, 15 May 2023 09:36:19 +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 CFC4A2F4; Mon, 15 May 2023 02:36:56 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1016B3F67D; Mon, 15 May 2023 02:36:10 -0700 (PDT) Date: Mon, 15 May 2023 10:36:08 +0100 From: Sudeep Holla To: Ricardo Neri Cc: Radu Rendec , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Pierre Gondois , Sudeep Holla , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 1/3] cacheinfo: Add arch specific early level initializer Message-ID: <20230515093608.etfprpqn3lmgybe6@bogus> References: <20230412185759.755408-1-rrendec@redhat.com> <20230412185759.755408-2-rrendec@redhat.com> <20230510191207.GA18514@ranerica-svr.sc.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230510191207.GA18514@ranerica-svr.sc.intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230515_023617_872285_693E5BA5 X-CRM114-Status: GOOD ( 16.43 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 10, 2023 at 12:12:07PM -0700, Ricardo Neri wrote: > Hi, > > I had posted a patchset[1] for x86 that initializes > ci_cacheinfo(cpu)->num_leaves during SMP boot. > It is entirely clear to me if this is just a clean up or a fix to some issue you faced ? Just wanted to let you know Prateek from AMD has couple of fixes [2] > This means that early_leaves and a late cache_leaves() are equal but > per_cpu_cacheinfo(cpu) is never allocated. Currently, x86 does not use > fetch_cache_info(). > > I think that we should check here that per_cpu_cacheinfo() has been allocated to > take care of the case in which early and late cache leaves remain the same: > > - if (cache_leaves(cpu) <= early_leaves) > + if (cache_leaves(cpu) <= early_leaves && per_cpu_cacheinfo(cpu)) > > Otherwise, in v6.4-rc1 + [1] I observe a NULL pointer dereference from > last_level_cache_is_valid(). > I think this is different issue as Prateek was just observing wrong info after cpuhotplug operations. But the patches manage the cpumap_populated state better with the patches. Can you please look at that as weel ? -- Regards, Sudeep [2] https://lore.kernel.org/all/20230508084115.1157-1-kprateek.nayak@amd.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel