Hello!
> Here is how it should work (Alex correct me if I'm wrong here).
You _were_ right. Now... I still do not know, I can only comment
and state that current code really looks funny. :-)
> Purpose of STATE_SCHED is to protect tasklet from being _scheduled_ on the several cpus at the same time.
Rather its purpose was not protective. When it was set, it meaned that
the function _will_ be run. tasklet_action was allowed to reset it
at any time before function is called. But not after, of course.
> When we run a tasklet we unlink it from the queue and clear STATE_SCHED to allow it to be scheduled again.
This can be made later, but before the function is called.
> tasklet_schedule calls tasklet_unlock after it schedules tasklet,
Hmm... but this opens one more bug: are schedules not lost, when
they are made while tasklet is running?
> we're not gonna schedule tasklet. And there is no point in locking tasklet on the UP machines.
It can be converted to spinlock. I felt a discomfort creating spinlock,
which never spins. :-)
And one more question:
> - cpu_raise_softirq(cpu, TASKLET_SOFTIRQ); <<<<
> - tasklet_unlock(t);
> - }
> - local_irq_restore(flags); <<<<
But Andrea has just tought me that this is invalid to call cpu_raise_softirq
in such context. No differences of netif_rx() here, all the issues are
the same.
> (Alex you can safely boot latest kernels now :)).
Thank you. I am not afraid of booting not-working kernels, even like this. :-)
I am afraid, when do not feel ground. After your analysis even direction to
ground is lost. :-)
Alexey
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:38 EST