From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933601Ab3BLRiT (ORCPT ); Tue, 12 Feb 2013 12:38:19 -0500 Received: from mail-da0-f52.google.com ([209.85.210.52]:34494 "EHLO mail-da0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932404Ab3BLRiR (ORCPT ); Tue, 12 Feb 2013 12:38:17 -0500 Date: Tue, 12 Feb 2013 09:38:12 -0800 From: Tejun Heo To: Hillf Danton Cc: Namhyung Kim , Rusty Russell , Andrew Morton , Ingo Molnar , LKML , Stable Subject: Re: [PATCH 2/2] stop_machine: dequeue work before signal completion Message-ID: <20130212173812.GG7348@htj.dyndns.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 10, 2013 at 01:26:11PM +0800, Hillf Danton wrote: > When a CPU is finally put down in either CPU_UP_CANCELLED or > CPU_POST_DEAD, cpu_stop_cpu_callback() signals immediate completion on > all cpu_stop_works still queued on the dead CPU; unfortunately, this > code is buggy in that it doesn't remove the canceled work items off > the stopper->works leaving it corrupted, which will trigger BUG_ON() > during CPU_UP_PREPARE if the CPU is brought back online. > > This bug isn't easily triggered because CPU_DOWN has to race against > cpu_stop calls and most, if not all, cpu stop users pin target CPUs. > > Fix it by popping each work item off stopper->works. > > Thanks Tejun for sharing commit message, again. > > Signed-off-by: Hillf Danton > Reviewed-by: Namhyung Kim > Cc: stable@vger.kernel.org Acked-by: Tejun Heo Andrew, this one too. Thank you! -- tejun