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] [day] [month] [year] [list]
Message-ID: <48EC847A.5060900@cs.columbia.edu>
Date:	Wed, 08 Oct 2008 05:59:22 -0400
From:	Oren Laadan <orenl@...columbia.edu>
To:	"Serge E. Hallyn" <serue@...ibm.com>
CC:	dave@...ux.vnet.ibm.com, containers@...ts.linux-foundation.org,
	jeremy@...p.org, linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: [RFC v5][PATCH 0/9] Kernel based checkpoint/restart



Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@...columbia.edu):
>> These patches implement basic checkpoint-restart [CR]. This version (v5)
>> supports basic tasks with simple private memory, and open files (regular
>> files and directories only). The main changes include rework of memory
>> restart code and response to feedback. See original announcements below.
>>
>> Oren.
> 
> At the kernel summit, it was asked whether at some point this CR work
> could be used as the basis for a new suspend to disk implementation.
> I answered that we don't plan to handle kernel threads.  In your
> experience, are there any reasons why eventually we couldn't eventually
> handle kernel threads?
> 
> -serge

As far as I can see, there isn't an inherent reason not to handle
kernel threads. However, I never looked deep into the problem.

The main issue that I can see with it is similar to what the
hibernation developers must tackle anyway - how to freeze kernel
threads when some of them may still be needed to take the system
down.

Assuming that is solved, then we're left with how to freeze the
kernel threads in a state that makes sense for a restart; for
regular tasks this is right before going back to user-land (*),
for kernel threads it may not be the best place :)

(*) however, tasks that are ptraced or in the middle of a vfork
will require special treatment - since upon freezing they cannot
be forced to that convenient position; so upon restart there must
be special code to make their behavior after restart compatible
with what they would have done originally - probably by emulation
as opposed to rebuilding their old kernel stack. For instance,
if a task was stopped due to ptrace before return from a syscall,
then upon restart it should return to that exact state.

So I'd assume that kernel threads could be treated in a similar
manner by special-casing, if necessary.

Question: I'd assume that at least for some of the kernel threads
a simple re-launch at restart will do; how many really require that
we save and restore their state ?

Oren

--
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