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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070110120123.52376578@freekitty>
Date:	Wed, 10 Jan 2007 12:01:23 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	Jarek Poplawski <jarkao2@...pl>
Cc:	Ben Greear <greearb@...delatech.com>,
	David Miller <davem@...emloft.net>,
	herbert@...dor.apana.org.au, dlstevens@...ibm.com,
	netdev@...r.kernel.org
Subject: Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)

On Wed, 10 Jan 2007 13:50:48 +0100
Jarek Poplawski <jarkao2@...pl> 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 <shemminger@...l.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html