Hi! > > > It seems that if a process calls wait_for_completion() right before suspend, > > > the other task supposed to complete its completion may be accidentally frozen > > > before it's able to do this. It looks like this happens to kseroid sometimes > > > on suspend-during-resume. > > > > You mean, when a suspend occurs so soon after a resume that the resume has > > fully completed yet? > > No. > > During resume, we boot the kernel, check if there's an image to read and > (if there's one) we freeze processes using the refrigerator (we need to get rid > of them so that we can restore the image safely). Then, it seems, on > some systems, freeze_processes() may be called before all of the compiled-in > drivers complete their initialization. In particular, kseriod calls usermodehelper > at that time, which makes it wait uninterruptibly for a helper process to > complete. If that helper process is frozen, we end up with the uninterruptible > kseriod that we can't freeze and _resume_ fails, which is not nice, especially > that we don't need to care for this kseriod, as we are going to restore > the image in a while ... > > Perhaps we should not use the refrigerator during resume, or we could use a > slightly modified version? I don't know. As we allow resume to be called from userland, other refrigerator is not really an option. We could insert mdelay before resume, or some equivalent trick... Pavel -- Boycott Kodak -- for their patent abuse against Java.
