On Fri, Feb 17, 2012 at 04:37:28PM -0500, Alan Stern wrote: > This patch (as1521) slightly improves the way usb-storage's > asynchronous scanning thread interacts with the freezer. Rather than > making itself freezable before waiting for the device to settle, the > routine won't make itself freezable until after the settling delay. > > This is just as correct as the existing code. If the freezer starts > up before the delay is over then the scanning thread will be ignored > until the delay ends, at which point it will immediately be frozen. > On the other hand, if the freezer starts up after the delay is over > then it will wait for the scanning thread to finish, as it does now. It looks to me like this restores the potential for the deadlock I was seeing previously. If freezing were to start after khubd starts processing a disconnection but before the scanning thread is awoken from its delay loop, can't we still end up usb-stor-scan being frozen while khubd is waiting on it? This just seems to shift the point where the freezing occurs as compared with pre-3.2. What if you move set_freezable to inside the body of the if statement on US_FLIDX_DONT_SCAN? Then we should only freeze if there isn't someone waiting in quiesce_and_remove_host. There'd still theoretically be a race, but the window would be so small that it seems unlikely that it would ever be a problem, and usb-stor-scan should still freeze if it's going to proceed with the scan. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
