Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932482AbbFRUJp (ORCPT ); Thu, 18 Jun 2015 16:09:45 -0400 Received: from www.linutronix.de ([62.245.132.108]:55465 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932431AbbFRUJc (ORCPT ); Thu, 18 Jun 2015 16:09:32 -0400 Date: Thu, 18 Jun 2015 22:09:31 +0200 (CEST) From: Thomas Gleixner To: Dave Hansen cc: Kanaka Juvva , glenn.p.williamson@intel.com, matt.fleming@intel.com, will.auld@intel.com, Andi Kleen , ananth.s.narayan@intel.com, LKML , andrew.j.herdrich@intel.com, Tony Luck , Peter Zijlstra , x86@kernel.org, mingo@redhat.com, "H. Peter Anvin" , luto@amacapital.net, dvlasenk@redhat.com, bp@alien8.de, peter.p.waskiewicz.jr@intel.com, imammedo@redhat.com, bp@suse.de, ross.zwisler@linux.intel.com, jacob.w.shin@gmail.com, dirk.j.brandewie@intel.com, vikas.shivappa@intel.com, edwin.verplanke@intel.com, tomasz.kantecki@intel.com Subject: Re: [PATCH v1 2/2] x86, perf,cqm: handle CPU hotplug In-Reply-To: <5583234E.5080807@linux.intel.com> Message-ID: References: <1434653369-5162-1-git-send-email-kanaka.d.juvva@linux.intel.com> <5583234E.5080807@linux.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 918 Lines: 26 On Thu, 18 Jun 2015, Dave Hansen wrote: > On 06/18/2015 12:47 PM, Thomas Gleixner wrote: > >> > @@ -1239,12 +1239,15 @@ static inline void cqm_pick_event_reader(int cpu) > >> > int phys_id = topology_physical_package_id(cpu); > >> > int i; > >> > > >> > + mutex_lock(&cache_mutex); > > I already explained it to Vikas. You CANNOT take a mutex in that code > > path as it runs with interrupts disabled on a CPU which cannot > > schedule. > > How did lockdep not blow up and scream about this? Dunno. I did not test that stuff. The might_sleep() in mutex_lock() should catch it as well, IF that code was ever executed AFTER boot on a running system. Thanks, tglx -- 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/