From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neeraj Upadhyay Subject: Re: [PATCH] cpu/hotplug: Fix rollback during error-out in takedown_cpu() Date: Wed, 5 Sep 2018 18:21:13 +0530 Message-ID: <5b0e528f-e597-9598-3ff6-b9e08ddb8165@codeaurora.org> References: <1536042803-6152-1-git-send-email-neeraju@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: josh@joshtriplett.org, peterz@infradead.org, mingo@kernel.org, jiangshanlai@gmail.com, dzickus@redhat.com, brendan.jackman@arm.com, malat@debian.org, linux-kernel@vger.kernel.org, sramana@codeaurora.org, linux-arm-msm@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org On 09/05/2018 05:53 PM, Thomas Gleixner wrote: > On Wed, 5 Sep 2018, Thomas Gleixner wrote: >> On Tue, 4 Sep 2018, Neeraj Upadhyay wrote: >>> ret = cpuhp_down_callbacks(cpu, st, target); >>> if (ret && st->state > CPUHP_TEARDOWN_CPU && st->state < prev_state) { >>> - cpuhp_reset_state(st, prev_state); >>> + /* >>> + * As st->last is not set, cpuhp_reset_state() increments >>> + * st->state, which results in CPUHP_AP_SMPBOOT_THREADS being >>> + * skipped during rollback. So, don't use it here. >>> + */ >>> + st->rollback = true; >>> + st->target = prev_state; >>> + st->bringup = !st->bringup; >> No, this is just papering over the actual problem. >> >> The state inconsistency happens in take_cpu_down() when it returns with a >> failure from __cpu_disable() because that returns with state = TEARDOWN_CPU >> and st->state is then incremented in undo_cpu_down(). >> >> That's the real issue and we need to analyze the whole cpu_down rollback >> logic first. > And looking closer this is a general issue. Just that the TEARDOWN state > makes it simple to observe. It's universaly broken, when the first teardown > callback fails because, st->state is only decremented _AFTER_ the callback > returns success, but undo_cpu_down() increments unconditionally. > > Patch below. > > Thanks, > > tglx As per my understanding, there are 2 problems here; one is fixed with your patch, and other is cpuhp_reset_state() is used during rollback from non-AP to AP state, which seem to result in 2 increments of st->state (one increment done by cpuhp_reset_state() and another by cpu_thread_fun()) . > ---- > --- a/kernel/cpu.c > +++ b/kernel/cpu.c > @@ -916,7 +916,8 @@ static int cpuhp_down_callbacks(unsigned > ret = cpuhp_invoke_callback(cpu, st->state, false, NULL, NULL); > if (ret) { > st->target = prev_state; > - undo_cpu_down(cpu, st); > + if (st->state < prev_state) > + undo_cpu_down(cpu, st); > break; > } > } > @@ -969,7 +970,7 @@ static int __ref _cpu_down(unsigned int > * to do the further cleanups. > */ > ret = cpuhp_down_callbacks(cpu, st, target); > - if (ret && st->state > CPUHP_TEARDOWN_CPU && st->state < prev_state) { > + if (ret && st->state == CPUHP_TEARDOWN_CPU && st->state < prev_state) { > cpuhp_reset_state(st, prev_state); > __cpuhp_kick_ap(st); > } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation