Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1203225 > unrolled thread

Re: [PATCH] cpu/cacheinfo: Fix teardown path

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] cpu/cacheinfo: Fix teardown path Borislav Petkov <bp@suse.de> - 2015-08-08 10:50 +0200
    Re: [PATCH] cpu/cacheinfo: Fix teardown path Greg KH <gregkh@linuxfoundation.org> - 2015-08-08 17:50 +0200
      Re: [PATCH] cpu/cacheinfo: Fix teardown path Philip Müller <philm@manjaro.org> - 2015-08-08 20:30 +0200
        Re: [PATCH] cpu/cacheinfo: Fix teardown path Borislav Petkov <bp@suse.de> - 2015-08-08 22:00 +0200
      Re: [PATCH] cpu/cacheinfo: Fix teardown path Borislav Petkov <bp@suse.de> - 2015-08-08 22:00 +0200

#1203225 — Re: [PATCH] cpu/cacheinfo: Fix teardown path

On Mon, Jul 27, 2015 at 09:58:05AM +0200, Borislav Petkov wrote:
> Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
> box. A fragment of the splat was enough to pinpoint the issue:

Bah, this goes to Greg and not to tip. Anyway, here's a version with
updated tags.

Greg, please queue for 4.2 as it fixes a hang.

Thanks.

---
From: Borislav Petkov <bp@suse.de>
Date: Mon, 27 Jul 2015 08:36:27 +0200
Subject: [PATCH] cpu/cacheinfo: Fix teardown path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
box. A fragment of the splat was enough to pinpoint the issue:

  task: f58e0000 ti: f58e8000 task.ti: f58e800
  EIP: 0060:[<c135a903>] EFLAGS: 00010206 CPU: 0
  EIP is at free_cache_attributes+0x83/0xd0
  EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000
  ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0
   DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
  CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0

cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor
while the respective teardown path cache_shared_cpu_map_remove() didn't.
Fix that.

From tglx's version: to be on the safe side, move the cacheinfo
descriptor check to free_cache_attributes(), thus cleaning up the
hotplug path a little and making this even more robust.

Reported-and-tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: <stable@vger.kernel.org> # 4.1
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-kernel@vger.kernel.org
Cc: manjaro-dev@manjaro.org
Cc: Philip Müller <philm@manjaro.org>
Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.org
Signed-off-by: Borislav Petkov <bp@suse.de>
---
 drivers/base/cacheinfo.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 764280a91776..e9fd32e91668 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -148,7 +148,11 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
 
 			if (sibling == cpu) /* skip itself */
 				continue;
+
 			sib_cpu_ci = get_cpu_cacheinfo(sibling);
+			if (!sib_cpu_ci->info_list)
+				continue;
+
 			sib_leaf = sib_cpu_ci->info_list + index;
 			cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
 			cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
@@ -159,6 +163,9 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
 
 static void free_cache_attributes(unsigned int cpu)
 {
+	if (!per_cpu_cacheinfo(cpu))
+		return;
+
 	cache_shared_cpu_map_remove(cpu);
 
 	kfree(per_cpu_cacheinfo(cpu));
@@ -514,8 +521,7 @@ static int cacheinfo_cpu_callback(struct notifier_block *nfb,
 		break;
 	case CPU_DEAD:
 		cache_remove_dev(cpu);
-		if (per_cpu_cacheinfo(cpu))
-			free_cache_attributes(cpu);
+		free_cache_attributes(cpu);
 		break;
 	}
 	return notifier_from_errno(rc);
-- 
2.5.0.rc2.28.g6003e7f

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1203290

On Sat, Aug 08, 2015 at 10:46:02AM +0200, Borislav Petkov wrote:
> On Mon, Jul 27, 2015 at 09:58:05AM +0200, Borislav Petkov wrote:
> > Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
> > box. A fragment of the splat was enough to pinpoint the issue:
> 
> Bah, this goes to Greg and not to tip. Anyway, here's a version with
> updated tags.
> 
> Greg, please queue for 4.2 as it fixes a hang.

What commit caused this issue?

And it's a bit late for 4.2, as you say 4.1 is also affected, I'll wait
for 4.3-rc1 to give this a chance to get some testing.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1203347

Hi Greg,

I bi-sected it to following commit:

0d55ba46bfbee64fd2b492b87bfe2ec172e7b056 is the first bad commit
commit 0d55ba46bfbee64fd2b492b87bfe2ec172e7b056
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Wed Mar 4 12:00:16 2015 +0000

    x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure

You can follow it on my github repo in rich detail:

https://github.com/philmmanjaro/linux41/blob/master/git-bisect.txt

kind regards
Philip Müller

Am 08.08.2015 um 17:41 schrieb Greg KH:
> On Sat, Aug 08, 2015 at 10:46:02AM +0200, Borislav Petkov wrote:
>> On Mon, Jul 27, 2015 at 09:58:05AM +0200, Borislav Petkov wrote:
>>> Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
>>> box. A fragment of the splat was enough to pinpoint the issue:
>>
>> Bah, this goes to Greg and not to tip. Anyway, here's a version with
>> updated tags.
>>
>> Greg, please queue for 4.2 as it fixes a hang.
> 
> What commit caused this issue?
> 
> And it's a bit late for 4.2, as you say 4.1 is also affected, I'll wait
> for 4.3-rc1 to give this a chance to get some testing.
> 
> thanks,
> 
> greg k-h
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1203362

On Sat, Aug 08, 2015 at 08:23:49PM +0200, Philip Müller wrote:
> Hi Greg,
> 
> I bi-sected it to following commit:
> 
> 0d55ba46bfbee64fd2b492b87bfe2ec172e7b056 is the first bad commit
> commit 0d55ba46bfbee64fd2b492b87bfe2ec172e7b056
> Author: Sudeep Holla <sudeep.holla@arm.com>
> Date:   Wed Mar 4 12:00:16 2015 +0000
> 
>     x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure
> 
> You can follow it on my github repo in rich detail:
> 
> https://github.com/philmmanjaro/linux41/blob/master/git-bisect.txt

Philip,

what is with you and top-posting? How hard is it not to do it?!

Please stop with the top-posting already.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1203361

On Sat, Aug 08, 2015 at 08:41:56AM -0700, Greg KH wrote:
> What commit caused this issue?

Apparently

 0d55ba46bfbe ("x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure")

Looks like moving x86 to the generic cacheinfo stuff uncovered this
shortcoming there...

> And it's a bit late for 4.2, as you say 4.1 is also affected, I'll wait
> for 4.3-rc1 to give this a chance to get some testing.

Right, I guess that's fine too as it'll trickle to stable eventually...

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web