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  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]
Date:	Thu, 11 Jan 2007 08:24:28 +0100
From:	Jarek Poplawski <jarkao2@...pl>
To:	Stephen Hemminger <shemminger@...l.org>
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, Jan 10, 2007 at 12:01:23PM -0800, Stephen Hemminger wrote:
...
> Don't rely on books too heavily, they can get out of date
> with a simple code change.

I've tried to find this in the code at the beginning
and got mislead by the path with PREEMPT_BKL.
I think the books are necessary to get general ideas
and I tried to check why would I get so wrong ideas.

> 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.

I again think we talk about different subjects. Maybe
it's because of this thread - but I don't talk about
Ben's original problem no more - it's a problem of
linux vlans.

Yesterday I did what I should do earlier - checked
this simple way, with printk, and now I have no doubts
it's a bug: if you add or remove vlan devices with
vconfig, register_vlan_device and unregister_vlan_dev
are called by ioctl and they use and change rcu
procetded data without preemption disabled so vlan
rcu hash lists could become corrupted or find results
could be wrong.

Regards,
Jarek P.
-
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

Powered by blists - more mailing lists