On Sun, 27 May 2001, Andrea Arcangeli wrote:
> Yes the stock kernel.
yep you are right.
i had this fixed too at a certain point, there is one subtle issue: under
certain circumstances tasklets re-activate the tasklet softirq(s) from
within the softirq handler, which leads to infinite loops if
On Sun, May 27, 2001 at 12:09:29PM -0700, David S. Miller wrote:
> "live lock". What do you hope to avoid by pushing softirq processing
> into a scheduled task? I think doing that is a stupid idea.
NOTE: I'm not pushing anything out of the atomic context, I'm using
ksoftirqd only to cure the
On Sun, May 27, 2001 at 09:05:50PM +0200, Ingo Molnar wrote:
>
> On Sun, 27 May 2001, Andrea Arcangeli wrote:
>
> > I mean everything is fine until the same softirq is marked active
> > again under do_softirq, in such case neither the do_softirq in do_IRQ
> > will run it (because we are in the
On Sun, 27 May 2001, Andrea Arcangeli wrote:
> I mean everything is fine until the same softirq is marked active
> again under do_softirq, in such case neither the do_softirq in do_IRQ
> will run it (because we are in the critical section and we hold the
> per-cpu locks), nor we will run it
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.
> #2 hard-IRQ interrupts
On Sun, 27 May 2001, Andrea Arcangeli wrote:
Yes the stock kernel.
yep you are right.
i had this fixed too at a certain point, there is one subtle issue: under
certain circumstances tasklets re-activate the tasklet softirq(s) from
within the softirq handler, which leads to infinite loops if
On Sun, May 27, 2001 at 09:05:50PM +0200, Ingo Molnar wrote:
On Sun, 27 May 2001, Andrea Arcangeli wrote:
I mean everything is fine until the same softirq is marked active
again under do_softirq, in such case neither the do_softirq in do_IRQ
will run it (because we are in the critical
On Sun, May 27, 2001 at 12:09:29PM -0700, David S. Miller wrote:
live lock. What do you hope to avoid by pushing softirq processing
into a scheduled task? I think doing that is a stupid idea.
NOTE: I'm not pushing anything out of the atomic context, I'm using
ksoftirqd only to cure the cases
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.
#2 hard-IRQ interrupts the
On Sun, 27 May 2001, Andrea Arcangeli wrote:
I mean everything is fine until the same softirq is marked active
again under do_softirq, in such case neither the do_softirq in do_IRQ
will run it (because we are in the critical section and we hold the
per-cpu locks), nor we will run it again
David S. Miller
> Ingo Molnar writes:
>> (unlike bottom halves, soft-IRQs do not preempt kernel code.)
> ...
>
> Since when do we have this rule? :-)
...
> You should check Softirqs on return from every single IRQ.
> In do_softirq() it will make sure that we won't run softirqs
> while already
Ingo Molnar writes:
> (unlike bottom halves, soft-IRQs do not preempt kernel code.)
...
Since when do we have this rule? :-)
> the two error cases are:
>
> #1 hard-IRQ interrupts user-space code, activates softirq, and returns to
> user-space code
>
> #2 hard-IRQ interrupts the
Ingo Molnar writes:
(unlike bottom halves, soft-IRQs do not preempt kernel code.)
...
Since when do we have this rule? :-)
the two error cases are:
#1 hard-IRQ interrupts user-space code, activates softirq, and returns to
user-space code
#2 hard-IRQ interrupts the idle
David S. Miller
Ingo Molnar writes:
(unlike bottom halves, soft-IRQs do not preempt kernel code.)
...
Since when do we have this rule? :-)
...
You should check Softirqs on return from every single IRQ.
In do_softirq() it will make sure that we won't run softirqs
while already doing so or
14 matches
Mail list logo
