linux-kernel - Re: [RFC PATCH] tasklet: ignore disabled tasklet in tasklet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Nov 2012 17:37:07 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Xiaotian Feng <xtfeng@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Xiaotian Feng <dannyfeng@...cent.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC PATCH] tasklet: ignore disabled tasklet in tasklet_action

On Tue, 6 Nov 2012 09:22:16 +0800 Xiaotian Feng <xtfeng@...il.com> wrote:

> On Tue, Nov 6, 2012 at 6:52 AM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> > On Fri,  2 Nov 2012 10:48:54 +0800
> > Xiaotian Feng <xtfeng@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/