Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH][ATM] use rtnl_{lock,unlock} during device operations (take 2) | Date | Fri, 06 Jun 2003 11:05:37 -0400 | From | chas williams <> |
| |
In message <20030606.040410.54190551.davem@redhat.com>,"David S. Miller" writes: >Basically it protects all networking administrative actions, add an >address for a device, up a device, down a device, add a route, attach >a packet scheduler to dev, etc. etc.
so should i hold rtnl across add/remove atm addresses on atm dev's? (but iw ouldnt hold rtnl across people just reading the list of atm addresses right?)
>Hmmm, this is not how RTNL works on netdevs. The SMP lock is held >around all walking, and at the very precise moment where we are >doing the actual device unlink from dev_base. rtnl is acquired at >top-level when we will change something.
>This is very different from how you are using the lock+rtnl scheme >for your ATM stuff.
ok, i was thinking i could use rtnl to protect readers. this makes the connect(dev = ANY) rather icky. some of the abuse by me in other places might be moot in the future. i am planning (or have done) to move all the vcc's onto a global list (ala many of the other protocol stacks). this makes the code for proc (and others) much cleaner since you just grab a read lock on the global vcc sklist instead of locking and interating each atm device. further, this will let atm interrupt handlers block a race with vcc close/removal. is this a bad plan? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |