Date: Sat, 4 Feb 2006 20:10:42 +0100
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Nigel Cunningham <nigel@suspend2.net>, suspend2-devel@lists.suspend2.net,
       linux-kernel@vger.kernel.org
Subject: Re: [ 00/10] [Suspend2] Modules support.
Message-ID: <20060204191042.GA3909@elf.ucw.cz>
References: <20060201113710.6320.68289.stgit@localhost.localdomain> <200602041159.00326.rjw@sisk.pl> <200602042108.52112.nigel@suspend2.net> <200602041238.06395.rjw@sisk.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200602041238.06395.rjw@sisk.pl>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1101
Lines: 33

Hi!

> > > 3) trying to treat uninterruptible tasks as non-freezeable should better
> > > be avoided (I tried to implement this in swsusp last year but it caused
> > > vigorous opposition to appear, and it was not Pavel ;-))
> > 
> > I'm not suggesting treating them as unfreezeable in the fullest sense. I 
> > still signal them, but don't mind if they don't respond. This way, if they 
> > do leave that state for some reason (timeout?) at some point, they still 
> > get frozen.
> 
> Yes, that's exactly what I wanted to do in swsusp. ;-)

It seems dangerous to me. Imagine you treated interruptible tasks like
that...

What prevent task from doing

	set_state(UNINTERRUPTIBLE);
	schedule(one hour);
	write_to_filesystem();
	handle_signal()?

I.e. it may do something dangerous just before being catched by
refrigerator.
								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/