mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@linuxmail.org>
Cc: Patrick Mochel <mochel@digitalimplant.org>,
	akpm@zip.com.au,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: -mm swsusp: do not default to platform/firmware
Date: Thu, 29 Jul 2004 09:39:29 +0200	[thread overview]
Message-ID: <20040729073929.GB828@elf.ucw.cz> (raw)
In-Reply-To: <1091061026.8873.78.camel@laptop.cunninghams>

Hi!

> > +I did found some kernel threads don't do it, and they don't freeze, and
> 
> "I found... threads that don't..."
> 
> > +so the system can't sleep. Is this a known behavior?
> > +
> > +A: All such kernel threads need to be fixed, one by one. Select place
> > +where it is safe to be frozen (no kernel semaphores should be held at
> > +that point and it must be safe to sleep there), and add:
> > +
> > +            if (current->flags & PF_FREEZE)
> > +                    refrigerator(PF_FREEZE);
> > +
> 
> Perhaps you should also add.
> 
> If the thread is needed for writing the image to storage, you should
> instead set the PF_NOFREEZE process flag when creating the thread.

Thanks, text is now:

Q: Kernel thread must voluntarily freeze itself (call 'refrigerator'). But
I found some kernel threads that don't do it, and they don't freeze, and
so the system can't sleep. Is this a known behavior?

A: All such kernel threads need to be fixed, one by one. Select place
where it is safe to be frozen (no kernel semaphores should be held at
that point and it must be safe to sleep there), and add:

            if (current->flags & PF_FREEZE)
                    refrigerator(PF_FREEZE);

If the thread is needed for writing the image to storage, you should
instead set the PF_NOFREEZE process flag when creating the thread.

I'll eventually push it, too.
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2004-07-29  7:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28 22:24 Pavel Machek
2004-07-28 23:14 ` Andrew Morton
2004-07-28 23:39   ` Pavel Machek
2004-07-28 23:43     ` Pavel Machek
2004-07-29  0:30       ` Nigel Cunningham
2004-07-29  7:39         ` Pavel Machek [this message]
2004-07-29  7:52           ` Nigel Cunningham
2004-08-02  6:15 ` Patrick Mochel
2004-08-02 15:30   ` Kevin Fenzi
2004-08-03 11:28     ` Karol Kozimor
2004-08-09 19:44       ` Pavel Machek
2004-08-08 17:13   ` Pavel Machek
2004-07-29  5:19 Li, Shaohua
2004-07-29  7:38 ` Pavel Machek
2004-07-29  8:03   ` Nigel Cunningham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040729073929.GB828@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=ncunningham@linuxmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®