On Tue, 21 Feb 2012, Seth Forshee wrote: > On Tue, Feb 21, 2012 at 01:16:32PM -0500, Alan Stern wrote: > > This patch (as1521b) fixes the interaction between usb-storage's > > scanning thread and the freezer. The current implementation has a > > race: If the device is unplugged shortly after being plugged in and > > just as a system sleep begins, the scanning thread may get frozen > > before the khubd task. Khubd won't be able to freeze until the > > disconnect processing is complete, and the disconnect processing can't > > proceed until the scanning thread finishes, so the sleep transition > > will fail. > > > > The implementation in the 3.2 kernel suffers from an additional > > problem. There the scanning thread calls set_freezable_with_signal(), > > and the signals sent by the freezer will mess up the thread's I/O > > delays, which are all interruptible. > > > > The solution to both problems is the same: Replace the kernel thread > > used for scanning with a delayed-work routine on the system freezable > > work queue. Freezable work queues have the nice property that you can > > cancel a work item even while the work queue is frozen, and no signals > > are needed. > > > > The 3.2 version of this patch solves the problem in Bugzilla #42730. > > > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > CC: Seth Forshee <seth.forshee@xxxxxxxxxxxxx> > > CC: <stable@xxxxxxxxxxxxxxx> > > > > --- > > > > V.2: Fix the unbind/freeze race by using a delayed-work routine > > instead of calling kthread_create(). > > This looks great. There doesn't appear to be any way for an untimely > device removal to interfere with freezing. > > Unfortunately I'm unable to fully test it at the moment. I haven't been > able to reproduce the issue with any kernel I've built over the past > couple of days, even older kernel versions that I'm certain exhibited > the issue previously, even though I can still see it with older builds > of the same kernel. Presumably this is because a toolchain update has > affected the timing. I'll work on getting a build I can test, but even > without testing I have high confidence that this solution will work. Okay, thanks. Is it okay to add your "Acked-by"? If you want to do reliable testing in situations that depend on relative timing, like this, there's a simple approach: Add one or two delays at strategic spots in the driver. Then you can easily force whatever race you're interested in to occur. Alan Stern -- 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
