Re: [PATCH][ATM] use rtnl_{lock,unlock} during device operations (take 2)

[chas williams]

In message <[e-mail]>,"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?