Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp10386536imu; Wed, 5 Dec 2018 23:30:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/Va3AeZD77+ywLU1rHFUAhvdynKaKesz/1F56gJslrLoZLkpe2rINikRn+ST7xkwcCnHmlp X-Received: by 2002:a17:902:29a7:: with SMTP id h36mr27554728plb.244.1544081446269; Wed, 05 Dec 2018 23:30:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544081446; cv=none; d=google.com; s=arc-20160816; b=W1Xjn82cm7z2BXU8ovBw3qMPq9SzFMwBevkJghbGjwhYdiCkt//Kz9H1+Ie85ixNk8 sLeecq8ovyBK1NPOhDwgA20ju0IGL3Jk6Qol+ld3LyQU2PGoq7fbhNub+fDBczMzkzcW UTxgj0JqJ8Wno7ByvWeHlnP6Qst5RhfQ5O01gCxV+Ffa0YNZzjQwfEvd9GZFRxNRFBR9 v18HIbYp2Iy8Uie71f0F2OlstpGRSQp9Y4VHvECLWcTLm2+ktfk6uFdD9lCFitPWxJrB 9ZOwtlea3S4jbiNnSqjnBZWaVtapICRO/Rg11AELJRmnjTOHT3Etx2udot+O24otRV2K rt+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=LZ5/aJrcwmn5FgdmyXkK1b9wL4SYDySg1Mv11U4TKnA=; b=U6+Mzy+lFNqfFfUvE1js5RUECHjjPB2TCXQD5uyLRRptD8pu8Q1/TKs9i6TJare8ja HjXk6YaGNp6VSiBr5bbEYNW1z6motF0svSKHS/94D3NW1Z4hmsWvwufdxHCqxjSAYY1Q U5fTFc8/yCrWL24BiFju40Ls1/qUPTOS74rv8LWKTtnRtppbkusWjd5tgKSmfYXRerwX iHfX+liywOgloST+nachSVCSGoRTVmtyaSegxa5qxm4/Fckv8XweYB9OPkJZ1gQ9czKR 8v7QiPrAzyGD7mhHHdgAswQU3Uo8sKBjQTbxpFcPvyXmbSPwwxVnFdj0KS90qUu2NrNw 7tgQ== 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=hygon.cn Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b137si20041703pga.394.2018.12.05.23.30.30; Wed, 05 Dec 2018 23:30:46 -0800 (PST) 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=hygon.cn Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729129AbeLFH2k (ORCPT + 99 others); Thu, 6 Dec 2018 02:28:40 -0500 Received: from [110.188.70.11] ([110.188.70.11]:4831 "EHLO spam1.hygon.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728294AbeLFH2k (ORCPT ); Thu, 6 Dec 2018 02:28:40 -0500 Received: from MK-FE.hygon.cn ([172.23.18.61]) by spam1.hygon.cn with ESMTP id wB67QXuM043280; Thu, 6 Dec 2018 15:26:33 +0800 (GMT-8) (envelope-from puwen@hygon.cn) Received: from cncheex01.Hygon.cn ([172.23.18.10]) by MK-FE.hygon.cn with ESMTP id wB67QMKj095378; Thu, 6 Dec 2018 15:26:23 +0800 (GMT-8) (envelope-from puwen@hygon.cn) Received: from pw-vbox.hygon.cn (172.23.18.44) by cncheex01.Hygon.cn (172.23.18.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Thu, 6 Dec 2018 15:26:28 +0800 From: Pu Wen To: , , , , CC: , Pu Wen Subject: [RFC PATCH RESEND] x86/cpu: Avoid endless loop to get the number of cache leaves Date: Thu, 6 Dec 2018 15:26:13 +0800 Message-ID: <1544081173-25059-1-git-send-email-puwen@hygon.cn> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.23.18.44] X-ClientProxiedBy: cncheex02.Hygon.cn (172.23.18.12) To cncheex01.Hygon.cn (172.23.18.10) X-MAIL: spam1.hygon.cn wB67QXuM043280 X-DNSRBL: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org To get the number of cache leaves on AMD or Hygon platform, it should get the value of cpuid leaf 0x8000001d. But on certain broken platform such as a not fullly implemented virtual platform(for example Xen), the value of the cpuid leaf will nerver be CTYPE_NULL, so the kernel will run into an endless loop. To fix this problem, add a new enum type CTYPE_MAX to limit the maximum cpuid accessing. Signed-off-by: Pu Wen --- arch/x86/kernel/cpu/cacheinfo.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c index dc1b934..7bd167f 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -121,7 +121,8 @@ enum _cache_type { CTYPE_NULL = 0, CTYPE_DATA = 1, CTYPE_INST = 2, - CTYPE_UNIFIED = 3 + CTYPE_UNIFIED = 3, + CTYPE_MAX = 4 }; union _cpuid4_leaf_eax { @@ -640,7 +641,7 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c) /* Do cpuid(op) loop to find out num_cache_leaves */ cpuid_count(op, i, &eax, &ebx, &ecx, &edx); cache_eax.full = eax; - } while (cache_eax.split.type != CTYPE_NULL); + } while (cache_eax.split.type != CTYPE_NULL && i != CTYPE_MAX); return i; } -- 2.7.4