Re: [patch] severe softirq handling performance bug, fix, 2.4.5

[David S. Miller]

[ Linus removed from the CC:, he wouldn't read any of this since
  he's in Japan currently :-)]

Andrea Arcangeli writes:
 > On Sat, May 26, 2001 at 07:59:28PM +0200, Ingo Molnar wrote:
 > > the two error cases are:
 > > 
 > >  #1 hard-IRQ interrupts user-space code, activates softirq, and returns to
 > >     user-space code
 > 
 > Before returning to userspace do_IRQ just runs do_softirq by hand from C
 > code.

Ok, someone agrees with me. :-)

 > >  #2 hard-IRQ interrupts the idle task, activates softirq and returns to
 > >     the idle task.
 > 
 > The problem only happens when we return to the idle task and a softirq
 > is been marked active again and we cannot keep running it or we risk to
 > soft deadlock.

I still fail to understand, won't the C code in do_IRQ() handle
this case as well?  What is so special about returning from an
interrupt to the idle task on x86?  And what about that special'ness
makes the code at the end of do_IRQ() magically not run?

In fact, with the do_IRQ() check _and_ the check in schedule() itself,
the only case entry.S has to really deal with is "end of system call"
which it does.

Andrea, I think you are talking about a deeper and different problem.
Specifically, a softirq that makes new softirqs happen, or something
like this.  Right?

Later,
David S. Miller
[e-mail]