public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
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 --]



  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