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.
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
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
>>
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
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