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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html