On Tue, 2010-04-06 at 19:17 +0200, Johannes Berg wrote: > 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. Aha; thanks for the clarification. Dan -- 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
