lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805072041.20210.rjw@sisk.pl>
Date:	Wed, 7 May 2008 20:41:19 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Matthew Wilcox <matthew@....cx>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Matt Helsley <matthltc@...ibm.com>,
	Cedric Le Goater <clg@...ibm.com>,
	Paul Menage <menage@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Liam Howlett <howlett@...il.com>
Subject: Re: [RFC][PATCH 2/2] Freezer: Try to handle killable tasks

On Wednesday, 7 of May 2008, Matthew Wilcox wrote:
> On Wed, May 07, 2008 at 12:07:55AM +0200, Rafael J. Wysocki wrote:
> > The introduction of TASK_KILLABLE allows the freezer to work in some situation
> > that it could not handle before.
> > 
> > Make the freezer handle killable tasks and add try_to_freeze() in some places
> > where it is safe to freeze a (killable) task.  Introduce the
> > wait_event_killable_freezable() macro to be used wherever the freezing of
> > a waiting killable task is desirable.
> 
> Why do you say that TASK_KILLABLE allows the freezer to work in some
> situations where it couldn't before?  If something's using one of the
> killable functions, it means that it knows how to clean up and unwind
> gracefully if the task receives a fatal signal.  I don't understand what
> connection there is to the freezer.

The reason why we don't freeze uninterruptible tasks is that we don't know
why they are in that state.  If one of tasks is uninterruptible for a
relatively long time, that may indicate a non-recoverable error making it
dangerous to put the system into a sleep state.  If the task is killable,
though, the situation is recoverable.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ