From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: suspend-devel@lists.sourceforge.net
Cc: pm list <linux-pm@lists.osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [linux-pm] [RFC][PATCH -mm 1/5] PM: Make freeze_processes SMP-safe
Date: Fri, 1 Dec 2006 22:19:43 +0100 [thread overview]
Message-ID: <200612012219.44076.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0612011615150.2629-100000@iolanthe.rowland.org>
On Friday, 1 December 2006 22:17, Alan Stern wrote:
> On Fri, 1 Dec 2006, Rafael J. Wysocki wrote:
>
> > On Friday, 1 December 2006 15:56, Alan Stern wrote:
> > > On Thu, 30 Nov 2006, Rafael J. Wysocki wrote:
> > >
> > > > > Here's what I mean. usb-storage's kernel thread is unfreezable, because
> > > > > it might be needed for reading or writing a memory image to a swap region.
> > > > > If there's an I/O error then usb-storage will try to issue a USB port
> > > > > reset, for which it needs to acquire the USB device's lock.
> > > > >
> > > > > Now various other tasks may acquire that lock, and they may even stop
> > > > > while holding it. However they should never get frozen while holding the
> > > > > lock -- which means they shouldn't get frozen at arbitrary times merely
> > > > > because they are stopped. They are careful to call try_to_freeze() only
> > > > > at times when they don't hold any locks.
> > > >
> > > > This means they are kernel threads, so they won't be entering
> > > > get_signal_to_deliver(), will they?
> > >
> > > Some of them are kernel threads and some of them are user threads. Only
> > > the kernel threads call try_to_freeze().
> > >
> > > > If they don't enter get_signal_to_deliver(), they can only be frozen where
> > > > they explicitly call try_to_freeze().
> > >
> > > What about the user threads?
> >
> > We send fake signals to them, so they enter get_signal_to_deliver() and they
> > call try_to_freeze() from there.
>
> Well then, see, you're doing exactly what you said should never happen --
> you are freezing a user thread while it might be holding a lock that the
> unfreezable usb-storage thread needs.
Well, the current code does exactly the same - it freezes userland tasks
by sending them fake signals (and there's no way to check if such a process
holds any locks at that time). Moreover, it's been doing that from day one
and my patch doesn't change that.
If you have an unfreezeable process that depends on locks that may be held
by userland tasks, then _this_ is a bug, IMHO.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2006-12-01 21:19 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-25 21:10 [RFC][PATCH -mm] PM: Change ordering of suspend and resume code Rafael J. Wysocki
2006-11-25 21:29 ` [RFC][PATCH -mm 1/5] PM: Make freeze_processes SMP-safe Rafael J. Wysocki
2006-11-26 7:47 ` Pavel Machek
2006-11-26 10:02 ` Rafael J. Wysocki
2006-11-26 11:15 ` Rafael J. Wysocki
2006-11-26 13:34 ` Rafael J. Wysocki
2006-11-26 19:48 ` Pavel Machek
2006-11-26 23:09 ` Rafael J. Wysocki
2006-11-26 23:28 ` Pavel Machek
2006-11-27 2:41 ` [linux-pm] " Alan Stern
2006-11-27 20:04 ` Rafael J. Wysocki
2006-11-27 10:50 ` Pavel Machek
2006-11-27 20:02 ` Rafael J. Wysocki
2006-11-29 23:56 ` Pavel Machek
2006-11-28 23:40 ` Rafael J. Wysocki
2006-11-29 23:55 ` Pavel Machek
2006-11-30 0:21 ` Rafael J. Wysocki
2006-11-30 15:07 ` Rafael J. Wysocki
2006-11-30 15:43 ` [linux-pm] " Alan Stern
2006-11-30 16:04 ` Rafael J. Wysocki
2006-11-30 19:23 ` Rafael J. Wysocki
2006-11-30 22:34 ` Alan Stern
2006-11-30 22:57 ` Rafael J. Wysocki
2006-12-01 14:56 ` Alan Stern
2006-12-01 19:57 ` Rafael J. Wysocki
2006-12-01 21:17 ` Alan Stern
2006-12-01 21:19 ` Rafael J. Wysocki [this message]
2006-12-01 22:07 ` Alan Stern
2006-12-01 23:38 ` Rafael J. Wysocki
2006-12-02 11:55 ` Pavel Machek
2006-12-02 15:39 ` Alan Stern
2006-12-03 11:17 ` Rafael J. Wysocki
2006-11-30 21:55 ` [Suspend-devel] " Rafael J. Wysocki
2006-11-26 19:45 ` [linux-pm] " Pavel Machek
2006-11-26 23:37 ` Luca
2006-11-25 21:34 ` [RFC][PATCH -mm 2/5] swsusp: Change code ordering in disk.c Rafael J. Wysocki
2006-11-25 21:38 ` [RFC][PATCH -mm 3/5] swsusp: Change code ordering in user.c Rafael J. Wysocki
2006-11-25 21:45 ` [RFC][PATCH -mm 4/5] swsusp: Add PLATFORM_SNAPSHOT and PLATFORM_RESTORE ioctls Rafael J. Wysocki
2006-11-26 19:51 ` [linux-pm] " Pavel Machek
2006-11-26 23:12 ` Rafael J. Wysocki
2006-11-26 23:29 ` Pavel Machek
2006-11-27 10:37 ` Pavel Machek
2006-11-25 21:49 ` [RFC][PATCH -mm 5/5] PM: Change code ordering in main.c Rafael J. Wysocki
2006-11-26 7:44 ` [RFC][PATCH -mm] PM: Change ordering of suspend and resume code Pavel Machek
2006-11-26 10:08 ` Rafael J. Wysocki
2006-11-26 21:31 ` Pavel Machek
2006-11-26 23:15 ` Rafael J. Wysocki
2006-11-30 14:02 ` Stefan Seyfried
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=200612012219.44076.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.osdl.org \
--cc=pavel@ucw.cz \
--cc=stern@rowland.harvard.edu \
--cc=suspend-devel@lists.sourceforge.net \
/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