Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 28 Aug 2003 18:17:22 +0200 | From | Juergen Quade <> | Subject | Re: tasklet_kill will always hang for recursive tasklets on a UP |
| |
On Thu, Aug 28, 2003 at 07:53:11PM +0400, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Here we have it! In my opintion, the line > > > > clear_bit(TASKLET_STATE_SCHED, &t->state); > > > > is just a _BUG_. > > No, really. The sense of tasklet_kill() is that tasklet is under complete > control of caller upon exit from it. This clear_bit just makes some (only > marginally useful) reinitialization for the case the user will want > to reuse the struct. Essentially, after tasklet_unlock_wait() you can do > everything with the struct, it is not an alive object anymore.
Because the function as it is written is useless, but with changing from "clear_bit" to "set_bit" it would be - at least partly - useful, I still believe, it is a bug. Does anybody know, who is responsible for the function?
> > 2. we should find some means to make it usable for recursive tasklets. > > I would not say it is easy. When tasklet is enqueued on another cpu you > have no way to stop it unless you are in process context, where you can > sit and wait for completion.
For sure, not easy. But tasklet_kill will mostly be called in process context, won't it?
Juergen. - 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/
| ![\](/images/icornerr.gif) |