On Tue, Jul 24, 2001 at 07:35:10PM +1000, Rusty Russell wrote:
> In message <20010723162909.D822@athlon.random> you write:
> > > Why not fix all the cases? Why have this wierd secret rule that
> > > cpu_raise_softirq() should not be called with irqs disabled?
> >
> > cpu_raise_softirq _can_ be called with irq disabled too just now, irq
> > enabled or disabled has no influence at all on cpu_raise_softirq.
>
> No, you are wrong. If I do (NOT in a hw interrupt handler):
>
> local_irq_save(flags);
> ...
> cpu_raise_softirq(smp_processor_id(), FOO_SOFTIRQ);
> ...
> local_irq_restore(flags);
>
> ksoftirqd won't get woken, and the FOO soft irq won't get run until
You are wrong, please check again all the code involved.
inline void cpu_raise_softirq(unsigned int cpu, unsigned int nr)
{
__cpu_raise_softirq(cpu, nr);
/*
* If we're in an interrupt or bh, we're done
* (this also catches bh-disabled code). We will
* actually run the softirq once we return from
* the irq or bh.
*
* Otherwise we wake up ksoftirqd to make sure we
* schedule the softirq soon.
*/
if (!(local_irq_count(cpu) | local_bh_count(cpu)))
wakeup_softirqd(cpu);
}
If you are not in hw interrupt local_irq_count is zero so you will run
wakeup_softirqd().
The fact irq are enabled or disabled has no influence on the logic.
> the next interrupt comes in. You solved (horribly) the analagous case
> for local_bh_disable/enable, but not this one.
I didn't changed at all local_bh_enable (except a fix for a missing
barrier()), local_bh_enable/disable was solved by Ingo in 2.4.6.
> Below as suggested in my previous email (x86 only, untested). I also
It seems you're duplicating the local_irq_count functionalty plus you
break local_bh_enable, from local_bh_enable you want to run the softirq
immediatly.
> added a couple of comments. There's still the issue of stack
> overflows if you get hit hard enough with interrupts (do_softirq is
> exposed to reentry for short periods), but that's separate.
do_softirq can be re-entered but on re-entry it will return immediatly
because local_bh_count will be non zero in such case, so the only stack
overhead of a re-entry is a few words so it cannot harm (if stack
overflows it cannot be because of do_softirq re-entry).
Andrea
-
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:24 EST