Re: 2.6.24 BUG: soft lockup - CPU#X

[Jarek Poplawski <jarkao2@gmail.com>]

On Sat, Mar 29, 2008 at 09:06:10AM +0800, Herbert Xu wrote:
> On Fri, Mar 28, 2008 at 04:29:53PM +0100, Jarek Poplawski wrote:
> >
> > But during this, now limited, time of qdisc_run() there is a contention
> > for queue_lock and probably some additional cache updating because of
> > this other enqueuing, which could be delayed especially if queue length
> > is above some level.
> 
> You mean delaying into a per-cpu queue? That sounds interesting.

I mean any delaying could be necessary here. After rethinking it seems
to me this solution with the flag could be wrong even after current fix.

The owner of the flag has to give up queue_lock for some time, and
because of this its chances for regaining the lock are worse: other CPUs
could take it in a loop, winning the cache, and adding packets, which
are imediately dumped (or requeued).

So, it would make a kind of reverse lockup situation. Then, even normal
contention for both locks seems safer against such races: throughput
could be worse, but probably no such "(soft)lockup" risk.

Regards,
Jarek P.