Subject: Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)

From: Stephen Hemminger <[email-masked]>
Date: Wed, 10 Jan 2007 12:01:23 -0800

On Wed, 10 Jan 2007 13:50:48 +0100
Jarek Poplawski <[email-masked]> wrote:

> On Wed, Jan 10, 2007 at 10:04:11AM +0100, Jarek Poplawski wrote:
> ...
> > It looks like you're talking about the right thing
> > and I'm a fool again! Now I try to find why I even 
> > had to pay for this. I read again and again adequate
> > chapters from R. Love and C. Benvenuti's books, see
> > a lot about kernel preemption in 2.6, but can't see
> > anything about preemption disabled in ioctls - maybe
> > I'm blind or they are badly translated. Now I look
> > into "Linux Device Drivers", see ch. 6 about ioctls,
> > blocking I/O and RCU, but nothing about preemption
> > disabled again. Maybe this is omited because it's
> > obvious to people who started hacking with earlier
> > kernels?
> 
> ... or maybe it's even more complicated...
> 
> For the time being, I revoke my critique of these books.
> 
> Jarek P. 

Don't rely on books too heavily, they can get out of date
with a simple code change.

The path that I am talking about is the receive skb path. All data
received goes through netif_receive_skb and that does rcu_read_lock().
This is done so that receive protocol list can be used with RCU (lock
free). Since receiving is a time critical path, we want to process
without having to do any locked operations; locked operations cause a
processor force a cache miss and are one of the main CPU overheads.
RCU requires no locked operation, but does prevent preemption.

-- 
Stephen Hemminger <[email-masked]>