21 Jul
2004
21 Jul
'04
7:35 p.m.
* Scott Wood <scott(a)timesys.com> wrote:
It appears, though, that recent kernel versions do
preempt_disable()
in ksoftirqd, apparently to support CPU hotplugging[1]. When I
originally made the patch (against 2.6.0), this wasn't the case.
Since it was done so recently, hopefully there are no cases since then
that have started depending on this behavior.
do_softirq() always did a local_bh_disable() which stops preemption, so
softirq processing was always non-preemptible.
If preempt-disabled softirqs (and thus a
local_bh_disable() that works
for mutual exclusion on the local CPU) become relied upon by random
pieces of kernel code, [...]
believe me, as someone who took part in the discussions that designed
softirqs years ago and cleaned up some of it later on, i can tell you
that this property of softirqs was and is fully intentional. It's not
just some side-effect that got relied on by random code - it was used
from day one on. E.g. it enables exclusion against softirq contexts
without having to use cli/sti.
trying to make softirqs preemptible surely wont fly for 2.6 and it will
also overly complicate the softirq model. What's so terminally wrong
about adding preemption checks to the softirq paths? It should solve the
preemption problem for good. The unbound softirq paths are well-known
(mostly in the networking code) and already have preemption-alike
checks.
Ingo