On Tue, 2010-04-06 at 09:23 -0700, Dan Williams wrote: > > Yes, I'm bit worried about possibility of a possible deadlock too. One > > solution would be to move the block acquiring scan_mtx and queueing > > scan_work outside of the work_mtx locked section, I'll take a look on > > that. In any case, this patch won't most likely fix all issues with the > > locking here. For example there's that checking if scan is in progress > > in the beginning of the work_work. After that it is still possible that > > the scan is started. So there's obviously need for some fixing in the > > locking yet to be done. > > One issue would be if the new scan request has different parameters than > the in-progress scan request. This is especially important when the > incoming scan request is for a specific SSID (hidden network probing) > while the ongoing one is not. Can we make sure that the patch at least > returns the error up the stack when the incoming scan is dropped? > Otherwise userspace has no idea that the specific SSID scan was dropped > on the floor, and just thinks that the hidden SSID wasn't found. There's no scan request being dropped -- it's just that we try to ask the hw to do the same scan twice without noticing that we've already asked it. johannes -- 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
