Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933472Ab2KFBhL (ORCPT ); Mon, 5 Nov 2012 20:37:11 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:56729 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754765Ab2KFBhJ (ORCPT ); Mon, 5 Nov 2012 20:37:09 -0500 Date: Mon, 5 Nov 2012 17:37:07 -0800 From: Andrew Morton To: Xiaotian Feng Cc: linux-kernel@vger.kernel.org, Xiaotian Feng , Thomas Gleixner , Ingo Molnar Subject: Re: [RFC PATCH] tasklet: ignore disabled tasklet in tasklet_action Message-Id: <20121105173707.94602896.akpm@linux-foundation.org> In-Reply-To: References: <1351824534-2861-1-git-send-email-xtfeng@gmail.com> <20121105145207.6d2fae92.akpm@linux-foundation.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2956 Lines: 64 On Tue, 6 Nov 2012 09:22:16 +0800 Xiaotian Feng wrote: > On Tue, Nov 6, 2012 at 6:52 AM, Andrew Morton wrote: > > On Fri, 2 Nov 2012 10:48:54 +0800 > > Xiaotian Feng wrote: > > > >> We met a ksoftirqd 100% issue, the perf top shows kernel is busy > >> with tasklet_action(), but no actual action is shown. From dumped > >> kernel, there's only one disabled tasklet on the tasklet_vec. > >> > >> tasklet_action might be handled after tasklet is disabled, this will > >> make disabled tasklet stayed on tasklet_vec. tasklet_action will not > >> handle disabled tasklet, but place it on the tail of tasklet_vec, > >> still raise softirq for this tasklet. Things will become worse if > >> device driver uses tasklet_disable on its device remove/close code. > >> The disabled tasklet will stay on the vec, frequently __raise_softirq_off() > >> and make ksoftirqd wakeup even if no tasklets need to be handled. > >> > >> This patch introduced a new TASKLET_STATE_HI bit to indicate HI_SOFTIRQ, > >> in tasklet_action(), simply ignore the disabled tasklet and don't raise > >> the softirq nr. In my previous patch, I remove tasklet_hi_enable() since > >> it is the same as tasklet_enable(). So only tasklet_enable() needs to be > >> modified, if tasklet state is changed from disable to enable, use > >> __tasklet_schedule() to put it on the right vec. > > > > gee, I haven't looked at the tasklet code in 100 years. I think I'll > > send this in Thomas's direction ;) > > > > The race description seems real and the patch looks sane to me. Are > > you sure we can get away with never clearing TASKLET_STATE_HI? For > > example, what would happen if code does a tasklet_hi_schedule(t) and > > later does a tasklet_schedule(t)? > > hmm, that will be a nightmare... > tasklet_schedule(t)/tasklet_hi_schedule(t) doesn't use list_head, they > simply > make t->next = NULL, then put t on the tail of > tasklet_vec/tasklet_hi_vec. If the code does a tasklet_hi_schedule() > and then a tasklet_schedule, the tasklet will stay on tasklet_vec and > tasklet_hi_vec .... tasklet_hi_action will handle it first and clear > the TASKLET_SCHED_SCHED bit, later, in tasklet_action, it will be > handled again and hit a BUG_ON ... Well, actually I meant if the caller reuses the tassklet_struct after its softirq has been run. > But if code does a tasklet_hi_schedule(), then tasklet_kil and later > does a tasklet_schedule(), we do need clear the TASKLET_STATE_HI. That as well ;) > Also > we need to remove the tasklet_hi_enable() as it is the same as > tasklet_enable() and there's > only one user.. > > I'll send you V2 patch soon, thanks. Sounds good. -- 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/