From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: ncunningham@cyclades.com
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: Re: freeze_processes questions
Date: Thu, 7 Apr 2005 00:41:45 +0200 [thread overview]
Message-ID: <200504070041.46418.rjw@sisk.pl> (raw)
In-Reply-To: <1112825259.3757.82.camel@desktop.cunningham.myip.net.au>
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
Hi,
On Thursday, 7 of April 2005 00:07, Nigel Cunningham wrote:
> Hi.
>
> On Thu, 2005-04-07 at 07:35, Rafael J. Wysocki wrote:
> > On Wednesday, 6 of April 2005 23:17, Pavel Machek wrote:
> > > > > > I don't think Rafael is suggesting ignoring them. He's suggesting what
> > > > > > I'm already doing:
> > > > > > - Signal so they enter the freezer if they leave the state;
> > > > > > - Don't count them when deciding whether freezing failed;
> > > > > > - Handle the case where they don't leave the state until post resume (I
> > > > > > let them enter the refrigerator, but have code in there to check whether
> > > > > > the freezer is still on).
> > > > > >
> > > > > > In this way, I handle kseriod and anything else uninterruptible without
> > > > > > any problems.
> > > > >
> > > > > What happens if a process owns a lock needed to suspend a device and it is
> > > > > waiting in TASK_UNINTERRUPTIBLE?
> > > >
> > > > Well, we're in trouble. :-)
> > > >
> > > > However, if any process that we have frozen owns such a lock, we're in trouble
> > > > too.
> > >
> > > No, we are not. Processes can't own any locks when they are in
> > > refrigerator... It is not ok to call refrigerator from any context
> > > where you own a lock.
> >
> > I didn't mean a lock in general, but a lock that is needed to suspend a device.
> > If a process holding that lock is frozen, the _suspend() routine for the device
> > won't complete, because it won't be able to get the lock. IOW it will go to
> > sleep and we are single-threaded at that time ... Or am I missing anything?
>
> Whenever this topic comes up, the discussion is always abstract. If
> someone could think of a lock that might actually deadlock suspending,
> we look seriously at the issue.
Well, (having thought about it for a while) why, actually, a device's _suspend()
routine would need such a lock? Devices are suspended on one CPU in
a single thread which can only (potentially) race with interrupt handlers ...
> In the meantime, all I can say, from roughly three years of developing
> and testing, is that it never seems to happen.
Well, I have much less experience, but I don't think it's likely to happen,
too. :-)
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-06 22:41 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
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 [this message]
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=200504070041.46418.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.osdl.org \
--cc=ncunningham@cyclades.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox