"David S. Miller" <[EMAIL PROTECTED]> writes:
> > the attached softirq-2.4.5-B0 patch fixes this problem by calling
> > do_softirq() from local_bh_enable() [if the bh count is 0, to avoid
> > recursion].
>
> Yikes! I do not like this fix.
>
> I'd rather local_bh_enable() not become a more heavy primitive.
>
> I know, in one respect it makes sense because it parallels how
> hardware interrupts work, but not this thing is a function call
> instead of a counter bump :-(
>
> Any other ideas how to zap this?
I think the right way to fix it is to do a final atomic check for softirqs
when the kernel is exited. To be atomic this check neededs to be done with
interrupts off until the kernel exited. I just implemented a very similar way
into the x86-64 kernel (which needs to turn off interrupts for kernel anyways
for other reasons, this just extends the cli area a bit). The same atomic
check is needed for race free check of need_schedule (which is still racy
on plain i386).
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
