From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: freeze_processes questions
Date: Tue, 5 Apr 2005 20:02:29 +0200 [thread overview]
Message-ID: <200504052002.30245.rjw@sisk.pl> (raw)
In-Reply-To: <200504051153.11481.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Hi,
On Tuesday, 5 of April 2005 11:53, Rafael J. Wysocki wrote:
> On Tuesday, 5 of April 2005 11:27, Pavel Machek wrote:
> > Hi!
> > >
> > > I have two questions regarding freeze_processes():
> > >
> > > 1) Shouldn't we take the TASK_UNINTERRUPTIBLE state into consideration? Now
> > > we will fail if a process is sleeping when we try to freeze it.
> >
> > We can't allow processes to sleep at arbitrary places. Therefore we
> > send UNINTERRUPTIBLE task a signal, and hope it can get into
> > refrigerator in time.
>
> Hm, AFAIK we can't kill an UNINTERRUPTIBLE process, can we? Which means that
> we can't deliver a signal to it too ...
Well, the problem is that signal_wake_up() is not sufficient to make
an uninterruptible task get the signal. It only sets TIF_SIGPENDING for the
task, which is not quite good, IMHO (when the task finally wakes up,
it gets the "signal" and enters refrigerator(), because it has PF_FREEZE set,
and stays there forever, as there's nothing that could clear PF_FROZEN for
it).
I think it may be fixed in one of the two ways:
1) We can treat uninterruptible tasks as non-freezable (in analogy to stopped
tasks) - if all of the other tasks are frozen, nothing can wake up an uninterruptible
task, so this seems to be a safe approach.
2) We can try to force uninterruptible tasks to get their "signals" anyway using
wake_up_state() directly on them (which I don't like as much).
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-04-05 18:02 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 9:20 freeze_processes questions Rafael J. Wysocki
2005-04-05 9:27 ` Pavel Machek
2005-04-05 9:53 ` Rafael J. Wysocki
2005-04-05 18:02 ` Rafael J. Wysocki [this message]
2005-04-05 18:17 ` Alan Stern
2005-04-05 18:33 ` Rafael J. Wysocki
2005-04-05 20:37 ` Pavel Machek
2005-04-05 22:46 ` Rafael J. Wysocki
2005-04-05 22:57 ` Pavel Machek
2005-04-05 23:10 ` Nigel Cunningham
2005-04-06 6:41 ` Rafael J. Wysocki
2005-04-06 19:06 ` Alan Stern
2005-04-06 20:52 ` Rafael J. Wysocki
2005-04-06 21:03 ` Alan Stern
2005-04-06 21:26 ` David Brownell
2005-04-06 21:17 ` Pavel Machek
2005-04-06 21:35 ` Rafael J. Wysocki
2005-04-06 22:07 ` Nigel Cunningham
2005-04-06 22:41 ` Rafael J. Wysocki
2005-04-07 14:41 ` Alan Stern
2005-04-07 17:17 ` Rafael J. Wysocki
2005-04-07 14:43 ` Alan Stern
2005-04-07 17:26 ` Rafael J. Wysocki
2005-04-07 9:11 ` Pavel Machek
2005-04-07 12:29 ` Rafael J. Wysocki
2005-04-07 12:47 ` Nigel Cunningham
2005-04-07 14:36 ` Alan Stern
2005-04-07 18:03 ` Rafael J. Wysocki
2005-04-07 20:00 ` Alan Stern
2005-04-07 20:59 ` Rafael J. Wysocki
2005-04-07 22:09 ` Alan Stern
2005-04-08 6:20 ` Pavel Machek
2005-04-08 9:13 ` Rafael J. Wysocki
2005-04-07 21:03 ` Rafael J. Wysocki
2005-04-08 6:23 ` Pavel Machek
2005-04-08 11:23 ` Rafael J. Wysocki
2005-04-11 23:59 ` Pavel Machek
2005-04-27 9:30 ` Li Shaohua
2005-04-27 9:53 ` Nigel Cunningham
2005-04-28 4:48 ` Li Shaohua
2005-04-28 5:05 ` Nigel Cunningham
2005-04-28 5:21 ` Li Shaohua
2005-04-28 5:49 ` Nigel Cunningham
2005-04-28 6:01 ` Li Shaohua
2005-04-28 6:21 ` Nigel Cunningham
2005-04-28 8:15 ` Pavel Machek
2005-04-28 8:14 ` Pavel Machek
2005-04-28 15:19 ` Stefan Seyfried
2005-04-28 18:47 ` Pavel Machek
2005-04-08 7:20 ` Pavel Machek
2005-04-06 21:34 ` David Brownell
2005-04-06 22:03 ` Nigel Cunningham
2005-04-06 22:20 ` David Brownell
2005-04-07 9:09 ` Pavel Machek
2005-04-08 6:23 ` Pavel Machek
2005-04-08 7:18 ` 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=200504052002.30245.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.osdl.org \
--cc=pavel@ucw.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.