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

Groups > linux.kernel > #1168253 > unrolled thread

Re: [PATCH v1 2/2] x86, perf,cqm: handle CPU hotplug

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 v1 2/2] x86, perf,cqm: handle CPU hotplug Thomas Gleixner <tglx@linutronix.de> - 2015-06-18 21:50 +0200
    Re: [PATCH v1 2/2] x86, perf,cqm: handle CPU hotplug Dave Hansen <dave.hansen@linux.intel.com> - 2015-06-18 22:10 +0200
      Re: [PATCH v1 2/2] x86, perf,cqm: handle CPU hotplug Thomas Gleixner <tglx@linutronix.de> - 2015-06-18 22:10 +0200

#1168253 — Re: [PATCH v1 2/2] x86, perf,cqm: handle CPU hotplug

On Thu, 18 Jun 2015, Kanaka Juvva wrote:

> Added lock in event reader function. The cqm_pick_event_reader() function
> accesses cqm_cpumask and it is critical section between this and
> cqm_stable().
> 
> This situation is true when a CPU is hotplugged. Mutex is used to protect
> the critical section.
> 
> Signed-off-by: Kanaka Juvva <kanaka.d.juvva@linux.intel.com>
> ---
>  arch/x86/kernel/cpu/perf_event_intel_cqm.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_cqm.c b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> index 1880761..e17e37f 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> @@ -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.

Sigh.

	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/

[toc] | [next] | [standalone]

#1168262

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?
--
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]

#1168263

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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web