Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure
From: Sudeep Holla
Date: Tue Mar 10 2015 - 10:22:31 EST
On Tue, Mar 10, 2015 at 11:53:35AM +0000, Sudeep Holla wrote:
Hi Boris,
On 10/03/15 11:37, Borislav Petkov wrote:
> Hi,
>
> I just triggered this is on rc3 + tip/master which has your patch. This
> is an Intel SNB. Ideas, already fixed?
>
No, not seen this before. I will test tip/master on my Intel i7 box
again and get back to you.
I was able to reproduce this and now I realise I had CONFIG_AMD_NB
disabled in my config earlier which hid this issue previously, sorry
for that.
The below patch fixed the issue on my Intel i7 box. I can post this
separately if required.
Regards,
Sudeep
From b081cbf26071f4c8ce51f270931387415ab1a06c Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla@xxxxxxx>
Date: Tue, 10 Mar 2015 13:49:58 +0000
Subject: [PATCH] x86: cacheinfo: fix cache_get_priv_group for Intel
processors
The private pointer provided by the cacheinfo is used to implement
the AMD L3 cache specific attributes using the northbridge pointer
obtained through cpuid4 registers. However, it's populated even on
Intel processors for Level 3 cache. This results in failure of
cacheinfo setup as shown below as cache_get_priv_group returns the
unintialised private attributes which are not valid for Intel
processors.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1 at fs/sysfs/group.c:102
internal_create_group+0x151/0x280()
sysfs: (bin_)attrs not set by subsystem for group: index3/
Modules linked in:
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc3+ #1
Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
ffffffff81cc6539 ffff88043be73bd8 ffffffff8184065b 0000000000000000
ffff88043be73c28 ffff88043be73c18 ffffffff8107301a ffffffff81eff038
0000000000000001 ffffffff81efef60 0000000000000000 ffffffff81e1c080
Call Trace:
[<ffffffff8184065b>] dump_stack+0x4f/0x7b
[<ffffffff8107301a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff81073096>] warn_slowpath_fmt+0x46/0x50
[<ffffffff81277531>] internal_create_group+0x151/0x280
[<ffffffff81277799>] sysfs_create_groups+0x49/0xa0
[<ffffffff815d8823>] device_add+0x3e3/0x680
[<ffffffff815de3d0>] cpu_device_create+0xc0/0xe0
[<ffffffff811da78a>] ? __kmalloc+0x20a/0x220
[<ffffffff815e15d6>] cache_add_dev+0x176/0x220
[<ffffffff81fc3528>] cacheinfo_sysfs_init+0x51/0x93
[<ffffffff81fc34d7>] ? container_dev_init+0x2f/0x2f
[<ffffffff81002110>] do_one_initcall+0xa0/0x200
[<ffffffff81f771e5>] kernel_init_freeable+0x1f5/0x27d
[<ffffffff818345b0>] ? rest_init+0xd0/0xd0
[<ffffffff818345be>] kernel_init+0xe/0xf0
[<ffffffff8184ad93>] ret_from_fork+0x53/0x80
[<ffffffff818345b0>] ? rest_init+0xd0/0xd0
---[ end trace 5505c77da0d6932a ]---
This patch fixes the issue by checking if the l3 cache indicies are
populated correctly(happens only on AMD processors) before initializing
the private attributes.
Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
Cc: Borislav Petkov <bp@xxxxxxx>
Cc: x86@xxxxxxxxxx
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index f98bdebcf047..63b7bb6e8492 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -556,11 +556,10 @@ cache_get_priv_group(struct cacheinfo *this_leaf)
{
struct amd_northbridge *nb = this_leaf->priv;
- if (this_leaf->level < 3)
+ if (this_leaf->level < 3 || !(nb && nb->l3_cache.indices))
return NULL;
- if (nb && nb->l3_cache.indices)
- init_amd_l3_attrs();
+ init_amd_l3_attrs();
return &cache_private_group;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/