On Fri, 2 Nov 2012 10:48:54 +0800 Xiaotian Feng <xtf...@gmail.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)? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
