[lkml]   [2003]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][ATM] use rtnl_{lock,unlock} during device operations (take 2)
In message <>,"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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:36    [W:0.078 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site