On 5/6/08, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > The real problem is with beaconing, the only way we could get around > > this issue is > > creating a local skb in which we store the beacons given to us, and > > after all iterations > > are over, write the beacons one by one to the hardware. > > Obviously this results in race conditions where the beacon might be > > written to the > > hardware while the interface is being removed... Which would mean we > > could end up > > having to cripple rt2x00 again and remove all support for virtual > > interfaces... :S > > > > Johannes, do you have any suggestions? > > Well you could > (a) keep your own BSS interfaces list but you might need a mutex and > two work structs to make it flawless > (b) provide, in mac80211, an iterator that takes the RTNL instead of > RCU, I think that should work But hadn't you removed the RTNL locking to make the multi-BSS code easier? I think I can code around the problem to make the ERP configuration do a simple check if any interface has short preamble, and if that is the case all interfaces will have short preamble. The same would go for short slot time. Apparently the current code was broken in that respect anyway since it would assume the timing of the last interface in the list. As for the beaconing, the only location I cannot get around updating the beacon in the driver from scheduled context is in the suspend/resume path. And I believe resuming a mac80211 network interface is already a source of problems anyway... Well I'll dive a bit deeper into this and see what can be done about this. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
