* [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves
@ 2018-11-05 12:53 Pu Wen
2018-11-15 17:21 ` Borislav Petkov
0 siblings, 1 reply; 4+ messages in thread
From: Pu Wen @ 2018-11-05 12:53 UTC (permalink / raw)
To: bp, tglx, mingo, hpa, x86, linux-kernel; +Cc: Pu Wen
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(Xen, for example),
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 <puwen@hygon.cn>
---
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves
2018-11-05 12:53 [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves Pu Wen
@ 2018-11-15 17:21 ` Borislav Petkov
2018-12-08 2:46 ` Pu Wen
0 siblings, 1 reply; 4+ messages in thread
From: Borislav Petkov @ 2018-11-15 17:21 UTC (permalink / raw)
To: Pu Wen; +Cc: tglx, mingo, hpa, x86, linux-kernel
On Mon, Nov 05, 2018 at 08:53:45PM +0800, Pu Wen wrote:
> 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(Xen, for example),
> 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 <puwen@hygon.cn>
> ---
> 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);
i is an int and CTYPE_MAX is enum _cache_type. Huh?
This works by chance because CTYPE_MAX is 4 and the termination CPUID
leaf is the 4th too.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves
2018-11-15 17:21 ` Borislav Petkov
@ 2018-12-08 2:46 ` Pu Wen
2018-12-08 11:12 ` Borislav Petkov
0 siblings, 1 reply; 4+ messages in thread
From: Pu Wen @ 2018-12-08 2:46 UTC (permalink / raw)
To: bp; +Cc: tglx, mingo, hpa, x86, linux-kernel, Pu Wen
Sorry for the late reply :)
On 2018/11/16 1:22, Borislav Petkov wrote:
>> @@ -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);
> i is an int and CTYPE_MAX is enum _cache_type. Huh?
How about define CTYPE_MAX like this:
#define CTYPE_MAX 4
> This works by chance because CTYPE_MAX is 4 and the termination CPUID
> leaf is the 4th too.
It will return CTYPE_NULL when accessing the 4th CPUID leaf in most of
the cases, but in certain case it will not. So I think it's better to
restrict the maximum CPUID access times to 4 for kernel robustness.
--
Regards,
Pu Wen
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves
2018-12-08 2:46 ` Pu Wen
@ 2018-12-08 11:12 ` Borislav Petkov
0 siblings, 0 replies; 4+ messages in thread
From: Borislav Petkov @ 2018-12-08 11:12 UTC (permalink / raw)
To: Pu Wen; +Cc: tglx, mingo, hpa, x86, linux-kernel
On Sat, Dec 08, 2018 at 10:46:54AM +0800, Pu Wen wrote:
> How about define CTYPE_MAX like this:
> #define CTYPE_MAX 4
How about you look at the definition of CPUID leaf 4 and think about it
a bit and realize that this is the wrong thing to do?
> It will return CTYPE_NULL when accessing the 4th CPUID leaf in most of
> the cases, but in certain case it will not.
Well, that's certain cases' problem, isn't it? How about fixing xen
instead?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-12-08 11:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-05 12:53 [PATCH] x86/cpu: Avoid endless loop to get the number of cache leaves Pu Wen
2018-11-15 17:21 ` Borislav Petkov
2018-12-08 2:46 ` Pu Wen
2018-12-08 11:12 ` Borislav Petkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).