Re: Seems like a race or unhandled situation with ksoftirqd scheduling/management - Oops missed the control flow in the generic irq.c as most targets use their own irq.c

[C Hanish Menon <hanishkvc@yahoo.com>]

Hi Andi

Andi Kleen wrote:
> At least i386 runs the softirqs at the end of do_IRQ.
> 
> ksoftirqd is just supposed to be a fallback mechanism for the case
> of soft irqs eating excessive runtime or one softirq triggering another
> (common case is networking and serial softirq for BH). It is not
> the primary way to run softirqs.

Oops, You are right, i386 and also the generic mips irq.c has code in
do_IRQ to call do_softirq.

But most of the target specific irq.c in mips, don't seem to follow this 
convention. Even when I started my port, I had based my interrupt 
subsystem after looking into some of these target specific irq.c's.

So I was expecting this call to softirqs occuring from within 
kernel/entry.S after ret_from_irq. And as there is no code there to this
end, I came to my flawed conclusion.

Sorry about this wrong assumption.
I have got the solution to my problem. However have to check out with 
the mips target guys has to how they are taking care of softirqs. When
they aren't calling do_softirq from do_IRQ or any other part of 
interrupt subsystem.

Keep :-)
HanishKVC