2010/11/3 Björn Smedman <bjorn.smedman@xxxxxxxxxxx> > Hi all, > > The beacon processing in ath9k is done in a tasklet. This tasklet may race > against beacon allocation/deallocation in process context. The patch below > is an attempt to point out / avoid these race conditions. My hope is that > this will stabilize ath9k in a use-case I'm interested in where ap vif > interfaces are added and removed quite often. > > This is purely an RFC, and it's probably synchronizing a bit too much. I'm > currently testing this patch with no obvious problems so far (except for > the part in xmit.c which I've commented out). More testing is necessary > but so is a rewrite of the patch anyway. > > Any thoughts? Anybody? In principle at least, don't you agree it's a bad idea letting the beacon tasklet race against the beacon allocation/deallocation? Do you think it's a good idea to disable the tasklet, or should we add some spin_lock_bh's instead? Best regards, Björn -- 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