From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0669A6E2D0; Thu, 25 Jan 2024 14:34:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.55.52.115 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706193267; cv=none; b=JZ9YUbgUxGe5MI9STRcHpC3R+TeQK1/weoykaWX04QWNawaACaxKk8S0Ge5ofvCsJM/rdRoe7Xy0M4rsdfP4NevmFLFgXHvrXnhCJjVjp7nUgvetH7zJCScebvT+rXUz3jzQ6cqO6P6HlHBbh961v02skTwXUvWqg1+75Mf4sIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706193267; c=relaxed/simple; bh=Vd0x1kY54QPZtj97cg5M3RjCoccZzQjOZTpbb5617AI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FAa+X+sUvKdhgwulp16miSqGoagGETelPa+XLWP/i+TxgMVHT8DQawpRDHn17mLpcPx+/hWG9x6Uxgz8VbEG5TfNF8SUDsS/5HVoLPykEZD/80LZn9D6/+XiSS5N5ZAngrN1fW1YOHSH1S+dk4vNVz97VRG99qI8BnIVpwOMTvw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VrhpNdaS; arc=none smtp.client-ip=192.55.52.115 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VrhpNdaS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706193266; x=1737729266; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Vd0x1kY54QPZtj97cg5M3RjCoccZzQjOZTpbb5617AI=; b=VrhpNdaSorJ8OHKvOJVZajF8hNHN/HM/2UDqEcSYEp7FsnaznTDXiFEG Pqk5rFV2k3m52g8pq2Pgu6e2fC+MIiTgc/jg6cOecJCIdlBAK53BPJUyy NzMBEwX2InpxHwlVTQV8ygLxMwoPoIcDqGZAf8dvjSPmf5l0WPuQLdiHb R0U6aLLW3DKl0dCaGXxB0bIDkEWOvYhdhVRQ9T+GhqDHw8BVoVcgprVuv 9xgXYs1D+Cc6bOnq9HREwdkLepr/dLvcitNVd/TsxT2LEbXMuuPSRlIWl EYnLdlFU5/hVQFUwT6Xu8v9wIWHSUwcspgMngyPEJOWEvheYQbi04s/zs A==; X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="401827557" X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="401827557" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2024 06:34:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="2438122" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa004.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2024 06:34:08 -0800 Date: Thu, 25 Jan 2024 06:35:33 -0800 From: Ricardo Neri To: Sudeep Holla Cc: x86@kernel.org, Andreas Herrmann , Catalin Marinas , Chen Yu , Len Brown , Radu Rendec , Pierre Gondois , Pu Wen , "Rafael J. Wysocki" , Srinivas Pandruvada , Will Deacon , Zhang Rui , Huang Ying , "Ravi V. Shankar" , stable@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 1/4] cacheinfo: Check for null last-level cache info Message-ID: <20240125143533.GA16226@ranerica-svr.sc.intel.com> References: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com> <20231212222519.12834-2-ricardo.neri-calderon@linux.intel.com> <20240125111544.xhiomitgeazxm7cw@bogus> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240125111544.xhiomitgeazxm7cw@bogus> User-Agent: Mutt/1.9.4 (2018-02-28) On Thu, Jan 25, 2024 at 11:15:44AM +0000, Sudeep Holla wrote: > On Tue, Dec 12, 2023 at 02:25:16PM -0800, Ricardo Neri wrote: > > Before determining the validity of the last-level cache info, ensure that > > it has been allocated. Simply checking for non-zero cache_leaves() is not > > sufficient, as some architectures (e.g., Intel processors) have non-zero > > cache_leaves() before allocation. > > > > Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). > > This function iterates over all online CPUs. However, a CPU may have come > > online recently, but its cacheinfo may not have been allocated yet. > > > > Cc: Andreas Herrmann > > Cc: Catalin Marinas > > Cc: Chen Yu > > Cc: Huang Ying > > Cc: Len Brown > > Cc: Radu Rendec > > Cc: Pierre Gondois > > Cc: Pu Wen > > Cc: "Rafael J. Wysocki" > > Cc: Sudeep Holla > > If you respin, you can address the below minor nit. I am fine as is as > well. > > Reviewed-by: Sudeep Holla Thank you for your review Sudeep! > > [...] > > > diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c > > index f1e79263fe61..967c5cf3fb1d 100644 > > --- a/drivers/base/cacheinfo.c > > +++ b/drivers/base/cacheinfo.c > > @@ -61,6 +61,9 @@ bool last_level_cache_is_valid(unsigned int cpu) > > if (!cache_leaves(cpu)) > > return false; > > > > + if (!per_cpu_cacheinfo(cpu)) > > + return false; > > + > > [nit] You can even combine this with above if condition. Sure, I can take care of this if a new version is needed as per feedback from the x86 maintainers.