Re: Re: freeze_processes questions

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

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.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]