Re: tasklet race condition

From: Jeff DeFouw (defouwj@purdue.edu)
Date: Wed Feb 23 2000 - 10:24:22 EST


On Wed, 23 Feb 2000 kuznet@ms2.inr.ac.ru wrote:

> Task is marked as SCHEDuled and it is not on this list when
> it is already scheduled on another CPU.

Hrm.. oops. I should have noticed that. The tasklets in my brain must
have stopped running also. :)

> It is very simple machine: SCHED flag means that tasklet is scheduled
> or about to be scheduled on some CPU. If it is set, the tasklet
> is already scheduled and will run soon on some cpu.

"will run soon" is what it should be. What's happening is that the actual
case becomes "will never run".

> If you want to test it, check not only this list but all the lists
> for all the CPUs. [It is dangerous! You have to add new spinlock
> to make this]

That's what I'll do then. I'll figure something out. I should add the
cpu id to the debug messages for starters.

> > tasklet never runs, and the other time it only runs once or twice.
>
> Exactly. Doing for (i=0;i<12;i++) mark_bh(xx) you will have
> BH running once, rather than 12 times. Tasklets are not different
> in this sense, they batch events.

Well, not exactly. What's really happening is infrequent_irqhandler()
{...; mark_bh(xx); ...;} where infrequent_irqhandler gets called many
times per second over at least a few seconds up to infinity. I guess
that's close to a for (;;) mark_bh(xx) with interrupts in the loop. I'm
aware that they batch. The problem is at some point they get lost. More
than 5 minutes will go by without the scheduled tasklet ever running and
it's queue status never changes.

--
Jeff DeFouw <defouwj@purdue.edu>

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:33 EST