Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp285172rwd; Wed, 17 May 2023 18:44:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4z2lWLV+++LjS1djFrfPQwnRPwh1TDd2Bkk8m7/I0B1j8J0BoJX8HUk/qmHTLrg/i3armB X-Received: by 2002:a05:6a00:1253:b0:64a:fa71:a98f with SMTP id u19-20020a056a00125300b0064afa71a98fmr2467243pfi.13.1684374289399; Wed, 17 May 2023 18:44:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684374289; cv=none; d=google.com; s=arc-20160816; b=AUpY9/KEF7YRypvZFuIsQjjMQB54dUchixvj4CKMtrda43p5VnSHAZp4K3JaZ50mDS xJzHKGQEkO3/+xV1W+W6yqg1VSeFEc7o9Tqx2gLDJyWSdHnlCCjlfs+QCLnm47/L8uQu Gfe306jhoKzMiEaT40xfXKsh+vINJ6DLF2gRwX71cSflmb6Q0esXViCr8BuWWynhhbxR GQ0aKix5qa9gaGC5mXnlwjawlUUGTzPSFJhiocoiOM/y8UQcBrNRPOAlqzoJGyJDTcYQ MARsjKE9zpcAwRLttkeES+BTAL/Swsw05RVnh6OvTpDoVd3Kf53PgRCBhFaqtYxW8p2q fZiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=6/va6Q3sda3MiPtKrDakqAj2KUxb7gxBj3qEJXVx/hE=; b=e0u36QzANbABlvgdoXy8WgUou60L8diUd7KpCFUZK7HLkbWtgkL0mR4t3LhvfMdOPl LcBFG1J9/rHAiS5J3ZFo+foPbtSv0GFY54iUDfQcmzBoiN/sfU3DC5u52xOiQ3hYTow4 pReA4Qu7c3eASi7aY062zO8IMI3Lb/F7n0CAYljFXW/RV5m+HdYxawBTyKejxQYWcF9G nEvYaUoyySBDg5ta3JdvlLf9CZsOTPBSBhGr2SrW/hf/93+YTFDb7vj9dq4zOcozjMTB ijLLi0EtHZtdgsqx48hObrUes9PnLWDwkqxhJcy0X9JSO84eul6RBAJJcyjPV59zgLjH R5UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bBHVBRWt; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e17-20020aa79811000000b006435b08fee8si422550pfl.196.2023.05.17.18.44.36; Wed, 17 May 2023 18:44:49 -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; dkim=pass header.i=@intel.com header.s=Intel header.b=bBHVBRWt; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229654AbjERBYI (ORCPT + 99 others); Wed, 17 May 2023 21:24:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjERBYI (ORCPT ); Wed, 17 May 2023 21:24:08 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 290BD30E4 for ; Wed, 17 May 2023 18:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684373047; x=1715909047; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fE7YgCkSDZ+nIO0tTZnSypacGkqjCiEQ9o1FV5TUhlM=; b=bBHVBRWt8avgTsUDhM9IO5E9YfnB5KNw4OyZVnjrvNj6WWQzB/9QCnfS fCajrt+MEoy2YykcTAGf20PvhRR6WnZw4FramOM8OA9lz8tzvI8MAPYkt m3ZEYbLUwV12jAPaVqJ+6k8Hg7qub65O6oI2gFifIQVz6GzxwjxlHNwSG nJpljjyb3X16KCehWl/36T0ZeduLHd8lYO+sxIM5+dxh95cSrrzbrxIv8 fdh0NaC9DcqUrwxFRYlPRhg4+cexbHgsKooDTGmokAZdKWKiXpJyRNs+t VPJKym+wuWQ7sPTK27Oc+sg01E147dOrG100vq4U6SPJWTiHHDhT0ZkiQ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10713"; a="355113382" X-IronPort-AV: E=Sophos;i="5.99,283,1677571200"; d="scan'208";a="355113382" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2023 18:24:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10713"; a="814121371" X-IronPort-AV: E=Sophos;i="5.99,283,1677571200"; d="scan'208";a="814121371" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga002.fm.intel.com with ESMTP; 17 May 2023 18:24:06 -0700 Date: Wed, 17 May 2023 18:27:03 -0700 From: Ricardo Neri To: Sudeep Holla Cc: Radu Rendec , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Pierre Gondois , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 1/3] cacheinfo: Add arch specific early level initializer Message-ID: <20230518012703.GA19967@ranerica-svr.sc.intel.com> References: <20230412185759.755408-1-rrendec@redhat.com> <20230412185759.755408-2-rrendec@redhat.com> <20230510191207.GA18514@ranerica-svr.sc.intel.com> <20230515093608.etfprpqn3lmgybe6@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230515093608.etfprpqn3lmgybe6@bogus> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 On Mon, May 15, 2023 at 10:36:08AM +0100, Sudeep Holla wrote: > 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] My first patch is a bug fix. The second patch is clean up that results from fixing the bug in patch 1. > > > 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 ? I verified that the patches from Prateek fix a different issue. I was able to reproduce his issue. His patches fixes it. I still see my issue after applying Prateek's patches. > > -- > Regards, > Sudeep > > [2] https://lore.kernel.org/all/20230508084115.1157-1-kprateek.nayak@amd.com Thank you for the suggestion! BR, Ricardo