On Fri, 16 Mar 2012, Oliver Neukum wrote: > Am Freitag, 16. M� 2012, 21:01:21 schrieb Rafael J. Wysocki: > > On Friday, March 16, 2012, Oliver Neukum wrote: > > > Am Freitag, 16. M� 2012, 15:10:30 schrieb Alan Stern: > > > > > What happens if the freezer starts during the window? It seems to me > > > > > that the task flushing work would block and could not be frozen. > > > > > > > > You're right. I didn't check for flush_delayed_work() calls when > > > > writing the patch. > > > > > > > > I guess it would be okay if we first do cancel_delayed_work_sync() and > > > > > > If you do that we would miss a change of medium. That is not really > > > acceptable. > > > > Can you elaborate a bit, please? What the exact scenario would be in that > > case? > > When the freezer races sd_open() after a disk has been changed. I don't understand. How would we miss a change of medium if we cancel the existing work item and resubmit in on a non-freezable workqueue? If the work item wasn't queued to begin with, cancelling it won't change anything. If the work item has already started running, cancelling it won't do anything. If the work item is queued but hasn't started running yet (perhaps because the workqueue is already frozen), the cancel call will succeed and then the work item will run on the non-freezable workqueue. In turn, the freezer will wait until disk_clear_events() finishes, which means it will wait until the work item finishes. Either way, the medium change will be detected. The one danger is that after the work item is cancelled, some other thread might resubmit it to the freezable workqueue before it can be put on the non-freezable workqueue. 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
