On Mon, 2007-09-03 at 11:29 +0200, Johannes Berg wrote: > And I'll also look into getting it non-atomic. We're > not protected against concurrent execution anyway, but I expect drivers > would handle that? Or do we want that here? We can't protect all > callbacks among each other anyway with the tx() callback etc... Ah, I see now, no way to do it because the networking core already locks around set_multicast_list using netif_tx_lock_bh, probably for good reason. And then propagating that lock to the master device is the right thing to do as well. Looks like you'll have to continue offloading the actual reconfiguration to the workqueue when called from set_multicast. And in fact, it seems that to protect against concurrent modification in different code paths I'll have to use the tx lock when calling this from the MLME code. Can you make sure that the filter will be reconfigured before further packets are transmitted, that is packets that are going to go into ->tx() after ->configure_filter()? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
