On Fri, 2007-04-20 at 13:32 -0700, David Miller wrote: > > Then again, holding rtnl in cfg80211 would simplify some things because > > we could pass in a netdev pointer instead of the ifindex for example. > > > > If you think I can justify holding rtnl in cfg80211 I'm certainly > > willing to change that. Global locks are just too suspicious to me ;) > > It is true that things like IPSEC configuration via xfrm_user.c > uses it's own mutex, so there is precedence for splitting up > the locking where things are truly seperate. :) > But changing things like MAC addresse changes, which you mention, do > fall into the existing scope of the RTNL semaphore. Actually, just thought about mac address change again, it is only permitted when devices are down anyway and at that point nothing can race since wireless devices that are down just store configuration for when they're up (or ignore it) > If it simplifies things, all the reason more to use it for cfg80211. A few places could use a netdev pointer instead of ifindex but I don't feel it's much of a simplification for callees. This is only an issue for two or three calls that cannot hold a netdev reference because the device will be removed by the driver/stack. Since the discussion came up due to dropping the rtnl from wext I think that it may be beneficial if we added rtnl locking to cfg80211 now to simplify migration away from wext which holds rtnl and then revisit the locking when we can drop wext completely from the mac80211 code. That would allow us to revisit rtnl locking for wext when we have completely migrated to cfg80211 and wext is only handled through cfg80211. Does that sound like an acceptable way forward? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
