Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1231047imm; Fri, 14 Sep 2018 13:36:42 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZltxfTWGVUFjeYsjhwdMbxdzSaRoVdy8/nxCUmcDGVHY549wQwk0dwSHsL2GwEgFOHGap6 X-Received: by 2002:a63:dd49:: with SMTP id g9-v6mr12991575pgj.356.1536957402612; Fri, 14 Sep 2018 13:36:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536957402; cv=none; d=google.com; s=arc-20160816; b=Zfy+Xdic254IWSh4aOEY2C9DiM0xhJb67v+Q3GwXF9d6qZK3M2VoRVSjIeWNJOAdok jynMKqxigW006yz80As20pqWSyp4OTeVs8+ebsPI2imRlFaMsE9APg6oBpjUXBVNcOLC nXwljsRkMy/uE512Ed16LzzQCb7sipVfVQvsJslIv/CubFXsGggni4UUb5iIh5chZ48s sL61NYXzguotw6GGxpQQotHt7HyzchhVhhAYRTYtMbxDxFPpcTV/VYU2GA4yB4ZxNPgw wjqZG74J5p/5Qj9Phub4FlXWH1DI+0B2/jhpHQoombG+ZfZmOp2qP38KnOIFBs9yP5Tb cJnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=IH8ymLcSsN2ndv0H6pcR8PRsGru0NQxLfGTObE4peZA=; b=SCnAM6K2t/0u9pGMk9KH6mNI+Uvr8EG3zUxhEoAaX/cx7hT4C93eKQDL0SjhyHI9G1 leLnaXu6riT8YpC/+mxZoFydqGol6Kxf9yJA+tLPrRVJrnM1oRV2uOk8+kckG9bx4hME lvYPUZWJNyP1corQZwMlPWkJqiMkI3K8rsWK/Vgo8zHqCNPz5p93S8bjeudKOsL43lIn az//qVsgQgfDRbKu/ngcLZshJ3EfI3Taudszb4wpZ2VaChejr2fbsXv1JsTSivqSBefh jSr4z651ci8MfwpJm/22Xx9tn/+e84A20qe/vZGHUuUKp7Z15bBx+ePpGEKz40UFaeak QaCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y18-v6si8372251pfb.161.2018.09.14.13.36.27; Fri, 14 Sep 2018 13:36:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728478AbeIOBvz (ORCPT + 99 others); Fri, 14 Sep 2018 21:51:55 -0400 Received: from mga05.intel.com ([192.55.52.43]:60391 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728366AbeIOBvx (ORCPT ); Fri, 14 Sep 2018 21:51:53 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2018 13:35:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,374,1531810800"; d="scan'208";a="263593822" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by fmsmga006.fm.intel.com with ESMTP; 14 Sep 2018 13:35:44 -0700 From: Fenghua Yu To: "Thomas Gleixner" , "Ingo Molnar" , "H Peter Anvin" , "Tony Luck" Cc: "Chatre, Reinette" , "Xiaochen Shen" , "Chen Yu" , "linux-kernel" , "x86" , "Fenghua Yu" Subject: [PATCH 9/9] x86/intel_rdt: Fix incorrect loop end condition Date: Fri, 14 Sep 2018 13:32:09 -0700 Message-Id: <1536957129-70380-10-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1536957129-70380-1-git-send-email-fenghua.yu@intel.com> References: <1536957129-70380-1-git-send-email-fenghua.yu@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Reinette Chatre In order to determine a sane default cache allocation for a new CAT/CDP resource group, all resource groups are checked to determine which cache portions are available to share. At this time all possible CLOSIDs that can be supported by the resource is checked. This is problematic if the resource supports more CLOSIDs than another CAT/CDP resource. In this case, the number of CLOSIDs that could be allocated are fewer than the number of CLOSIDs that can be supported by the resource. Limit the check of closids to that what is supported by the system based on the minimum across all resources. Fixes: 95f0b77ef ("x86/intel_rdt: Initialize new resource group with sane defaults") Signed-off-by: Reinette Chatre Signed-off-by: Fenghua Yu --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c index fac99f81d02f..90b76c1ebd70 100644 --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c @@ -2370,7 +2370,7 @@ static int rdtgroup_init_alloc(struct rdtgroup *rdtgrp) d->new_ctrl = r->cache.shareable_bits; used_b = r->cache.shareable_bits; ctrl = d->ctrl_val; - for (i = 0; i < r->num_closid; i++, ctrl++) { + for (i = 0; i < closids_supported(); i++, ctrl++) { if (closid_allocated(i) && i != closid) { mode = rdtgroup_mode_by_closid(i); if (mode == RDT_MODE_PSEUDO_LOCKSETUP) -- 2.19.0