On Fri, 1 Dec 2006, Rafael J. Wysocki wrote: > Well, the current code does exactly the same - it freezes userland tasks > by sending them fake signals (and there's no way to check if such a process > holds any locks at that time). Moreover, it's been doing that from day one > and my patch doesn't change that. Obviously the scenario I described is very unlikely. It would depend on a user program doing exactly the wrong thing at the wrong time, _and_ using a USB mass storage device for swapping, _and_ getting an I/O error while reading or writing the memory image. > If you have an unfreezeable process that depends on locks that may be held > by userland tasks, then _this_ is a bug, IMHO. In this case it isn't absolute dependence. If usb-storage isn't able to obtain the lock it needs, then it times out after 1 second and simply doesn't reset the device. Still, you would have your work cut out trying to find all the places in the kernel where an unfreezable process takes a lock which might be held by a user process. For instance, I doubt that all the workqueue threads could pass this test. Alan Stern
