linux-kernel - Re: [RFC][PATCH -mm] Freezer: Handle uninterruptible tasks

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]

Date:	Sat, 7 Jul 2007 19:13:42 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Pavel Machek <pavel@....cz>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Oliver Neukum <oliver@...kum.org>,
	Miklos Szeredi <miklos@...redi.hu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC][PATCH -mm] Freezer: Handle uninterruptible tasks

Hi.

On Saturday 07 July 2007 17:50:18 Pavel Machek wrote:
> Hi!
> 
> > The main limitation of the freezer is that it cannot handle 
uninterruptible
> > tasks.  Namely, if there are uninterruptible tasks in the system, the 
freezer
> > returns an error, which makes it impossible to suspend the system.
> ...
> > Unfortunately, this mechanism also leads to severe limitations, such as 
that it
> > makes the freezer unable to handle systems using FUSE in a reliable way.
> > 
> > This patch makes the freezer skip uninterruptible user space tasks (ie. 
such
> > that have an mm of their own) when counting the tasks to be frozen.  As a
> > result, these tasks have the TIF_FREEZE and TIF_SIGPENDING flags set, but 
the
> > freezer doesn't wait for them to enter the refrigerator.  Nevertheless, 
they
> > will enter the refrigerator as soon as they change their state.
> 
> I don't think we can do that. I suspect rename looks like:
> 
> 	write directory entry in source
> A)	(uninterruptible wait for write)
> 	write directory entry in destination
> 	(uninterruptible wait for write)
> 	write something else
> 
> If we freeze some task in place "A)", we'll write to the disk when the
> directory write is finished :-(.

Renaming is a single syscall, so won't the process get frozen when the syscall 
finishes? The sys_sync will also help here - it will ensure the rename gets 
flushed before we start on freezing kernel threads.

Perhaps you've just found more logic for keeping the sys_sync there?

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Content of type "application/pgp-signature" skipped