On Tue, Jan 09, 2007 at 09:10:45AM +0100, Jarek Poplawski wrote: > On Mon, Jan 08, 2007 at 10:03:50AM -0800, Stephen Hemminger wrote: ... > > > > * Must be invoked with RCU read lock (no preempt) > > > > */ > > > > struct net_device *__find_vlan_dev(struct net_device *real_dev, > > > > ... > > > > > > > > But later in this file no sign of disabling preemption > > > > for these calls and for hlist_add_head_rcu and hlist_del_rcu. > > > > > > > > I can't imagine how this works? > > > > Preempt is already disabled on the receive path. > > I'm not sure you're talking about the same thing -
Hello Stephen, 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? When I added to this things like: "If the mutex is not available right now, it will sleep until it can get it." and "It is illegal to block while in an RCU read-side critical section." I didn't even try to think about mutex or malloc with GFP_KERNEL inside RCU block. I'm enormously grateful you didn't lose patience in guiding me yet - I hope it'll save this list from nervous breakdown. Many thanks and regards as always, Jarek P. PS: probably you could profit from this some day and write something like "Linux Internals for Dummies" - it would be simple cut & paste of my discoveries and your responses! - 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
