Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

2017-10-10 Thread Michael Ellerman
Thomas Gleixner writes: ... > > So no, the lockdep assertion triggers in #1 and #2 because > >#1 does definitely not hold it > >#2 is indirectily protected, but we have no way to express that to lockdep > > So yes, it's safe for both cases to remove that assertion.

Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

2017-10-05 Thread Thomas Gleixner
Thiago, On Thu, 5 Oct 2017, Thiago Jung Bauermann wrote: > Thomas Gleixner writes: > It doesn't look like powerpc uses arch_update_cpu_topology differently > than other arches. Are you saying that all callers of the function > should be holding cpu_hotplug_lock? No. I didn't

Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

2017-10-05 Thread Thiago Jung Bauermann
Hello Thomas, Thanks for your comments. Thomas Gleixner writes: > On Wed, 4 Oct 2017, Thiago Jung Bauermann wrote: > >> It turns out that not all paths calling arch_update_cpu_topology hold >> cpu_hotplug_lock, but that's ok because those paths aren't supposed to race >>

Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

2017-10-05 Thread Thomas Gleixner
On Wed, 4 Oct 2017, Thiago Jung Bauermann wrote: > It turns out that not all paths calling arch_update_cpu_topology hold > cpu_hotplug_lock, but that's ok because those paths aren't supposed to race > with any concurrent hotplug events. > > Callers of arch_update_cpu_topology are expected to

[PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

2017-10-04 Thread Thiago Jung Bauermann
It turns out that not all paths calling arch_update_cpu_topology hold cpu_hotplug_lock, but that's ok because those paths aren't supposed to race with any concurrent hotplug events. Callers of arch_update_cpu_topology are expected to know what they are doing when they call the function without