public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC] [PATCH 00/13] Introduce task_pid api
@ 2005-11-14 21:23 Serge E. Hallyn
  2005-11-14 21:23 ` [RFC] [PATCH 01/13] Change pid accesses: drivers Serge E. Hallyn
                   ` (16 more replies)
  0 siblings, 17 replies; 86+ messages in thread
From: Serge E. Hallyn @ 2005-11-14 21:23 UTC (permalink / raw)
  To: linux-kernel; +Cc: Hubertus Franke, Dave Hansen

--

I'm part of a project implementing checkpoint/restart processes.
After a process or group of processes is checkpointed, killed, and
restarted, the changing of pids could confuse them.  There are many
other such issues, but we wanted to start with pids.

This patchset introduces functions to access task->pid and ->tgid,
and updates ->pid accessors to use the functions.  This is in
preparation for a subsequent patchset which will separate the kernel
and virtualized pidspaces.  This will allow us to virtualize pids
from users' pov, so that, for instance, a checkpointed set of
processes could be restarted with particular pids.  Even though their
kernel pids may already be in use by new processes, the checkpointed
processes can be started in a new user pidspace with their old
virtual pid.  This also gives vserver a simpler way to fake vserver
init processes as pid 1.  Note that this does not change the kernel's
internal idea of pids, only what users see.

The first 12 patches change all locations which access ->pid and
->tgid to use the inlined functions.  The last patch actually
introduces task_pid() and task_tgid(), and renames ->pid and ->tgid
to __pid and __tgid to make sure any uncaught users error out.

Does something like this, presumably after much working over, seem
mergeable?

thanks
-serge


^ permalink raw reply	[flat|nested] 86+ messages in thread
* RE: [RFC] [PATCH 00/13] Introduce task_pid api
@ 2005-11-16  2:24 Hua Zhong (hzhong)
  2005-11-16 17:52 ` Bernard Blackham
  0 siblings, 1 reply; 86+ messages in thread
From: Hua Zhong (hzhong) @ 2005-11-16  2:24 UTC (permalink / raw)
  To: Ray Bryant, Serge E. Hallyn; +Cc: linux-kernel, Hubertus Franke, Dave Hansen

I did some checkpoint/restart work on Linux about 5 years ago (you may
still be able to google "CRAK"), so I'm jumping in with my 2 cents.

> Personally, I think that these assumptions are incorrect for a 
> checkpoint/restart facility.   I think that:
> 
> (1)  It is really only possible to checkpoint/restart a 
> cooperative process.

It's hard, but not impossible, at least theoretically.

> For this to work with uncooperative processes you have to 
> figure out (for example) how to save and restore the file 
> system state.  (e.g. how do you 
> get the file position set correctly for an open file in the 
> restored program instance?)

This is actually one of the simplest problems in checkpoint/restart.

You'd need kernel support to save the state, and restart could be done
entirely in user space to restore the file descriptors.

> And this doesn't even consider what to do with open network 
> connections.

Right, this is really hard. I played with it 5 years ago and I had semi
success on restoring network connections (with my limited understanding
on Linux networking and some really ugly hacks). I could restart a
killed remote Emacs X session with about 50% success rate.

> Similarly, what does one do about the content of System V 
> shared memory regions or the contents of System V semaphores?   I'm
sure 
> there are many more such problems we can come up with a careful study
of the 
> Linux/Unix API.
>
> (Note that "cooperation" in this context can also mean 
> "willing to run inside of a container of some kind that supports
checkpoint/restart".)
> 
> So you can probably only checkpoint the process at certain 
> points in its lifetime, points which the application should be willing
to 
> identify in some way.    And I would argue that at such points in
time, you 
> can require that the current register state doesn't include the
results of a 
> system call such as getpid(), couldn't you?

Again, it IS very hard, but I don't think it's impossible to have
transparent checkpoint/restart. I mean, it cant be more difficult than
writing Linux from scratch, can it? :-)

> So, I guess my question is wrt the task_pid API is the 
> following:   Given that there are a lot of other problems to solve
before transparent 
> checkpointing of uncooperative processes is possible, why should this 
> partial solution be accepted into the main line kernel and "set in
stone" so to speak?

I agree with this. Before we see a mature checkpoint/restart solution
already implemented, there is no point in doing the vpid thing.

^ permalink raw reply	[flat|nested] 86+ messages in thread

end of thread, other threads:[~2005-12-19 14:06 UTC | newest]

Thread overview: 86+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-14 21:23 [RFC] [PATCH 00/13] Introduce task_pid api Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 01/13] Change pid accesses: drivers Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 02/13] Change pid accesses: most archs Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 03/13] Change pid accesses: filesystems Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 04/13] Change pid accesses: include/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 05/13] Change pid accesses: ipc Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 06/13] Change pid accesses: kernel/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 07/13] Change pid accesses: lib/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 08/13] Change pid accesses: mm/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 09/13] Change pid accesses: net/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 10/13] Change pid accesses: security/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 11/13] Change pid accesses: sound/ Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 12/13] Change pid accesses: ia64 and mips Serge E. Hallyn
2005-11-15 23:08   ` Keith Owens
2005-11-16 11:58     ` Serge E. Hallyn
2005-11-16 13:53     ` Serge E. Hallyn
2005-11-14 21:23 ` [RFC] [PATCH 13/13] Define new task_pid api Serge E. Hallyn
2005-11-14 23:36 ` [RFC] [PATCH 00/13] Introduce " Paul Jackson
2005-11-15  1:01   ` Serge E. Hallyn
2005-11-15  1:35     ` Paul Jackson
2005-11-15  1:51     ` Paul Jackson
2005-11-15  2:29       ` Serge E. Hallyn
2005-11-15  3:37         ` Paul Jackson
2005-11-15  5:15           ` Serge E. Hallyn
2005-11-15  6:35             ` Paul Jackson
2005-11-15  8:11               ` Serge E. Hallyn
2005-11-15  9:06                 ` Paul Jackson
2005-11-15 10:07                   ` Dave Hansen
2005-11-15 18:10                     ` Paul Jackson
2005-11-15 11:59                   ` Robin Holt
2005-11-15 13:32                   ` Serge E. Hallyn
2005-11-15 14:37                     ` Hubertus Franke
2005-11-15 18:39                       ` Paul Jackson
2005-11-15 18:54                         ` Hubertus Franke
2005-11-15 19:00                   ` Serge E. Hallyn
2005-11-15 19:17                     ` Hubertus Franke
2005-11-15 22:11                     ` Paul Jackson
2005-11-15 23:15                       ` Cedric Le Goater
2005-11-15 23:28                         ` Paul Jackson
2005-11-15 16:47             ` Greg KH
2005-11-15 17:08               ` Serge E. Hallyn
2005-11-15 17:33               ` Dave Hansen
2005-11-15  5:51   ` Serge E. Hallyn
2005-11-13 15:22     ` Pavel Machek
2005-11-16 19:36       ` Kyle Moffett
2005-11-16 20:36         ` Pavel Machek
2005-11-16 20:48           ` Dave Hansen
2005-11-19 23:30             ` Pavel Machek
2005-11-20 22:38               ` Serge E. Hallyn
2005-12-07 14:53                 ` Eric W. Biederman
2005-11-20 23:29               ` Nix
2005-11-16 21:07           ` Paul Jackson
2005-11-16 20:24       ` Dave Hansen
2005-11-15 13:34   ` Serge E. Hallyn
2005-11-15 11:17 ` Robin Holt
2005-11-15 12:01   ` Dave Hansen
2005-11-15 19:21 ` Ray Bryant
2005-11-15 19:41   ` Serge E. Hallyn
2005-11-15 20:30     ` Ray Bryant
2005-11-15 21:05       ` Serge E. Hallyn
2005-11-15 22:43         ` Paul Jackson
2005-11-15 22:55       ` Cedric Le Goater
2005-11-16  1:12         ` Paul Jackson
2005-12-07 14:46 ` Eric W. Biederman
2005-12-07 17:47   ` Dave Hansen
2005-12-07 17:55     ` Arjan van de Ven
2005-12-07 18:09       ` Dave Hansen
2005-12-07 19:00         ` Arjan van de Ven
2005-12-07 19:42           ` Eric W. Biederman
2005-12-07 22:13           ` Dave Hansen
2005-12-07 22:20             ` Arjan van de Ven
2005-12-12 10:55               ` Dave Airlie
2005-12-19 14:04                 ` Eric W. Biederman
2005-12-07 19:19     ` Eric W. Biederman
2005-12-07 21:40       ` Dave Hansen
2005-12-07 22:17         ` Eric W. Biederman
2004-12-14 15:23           ` Pavel Machek
2005-12-14 13:40             ` Arjan van de Ven
2005-12-14 16:29               ` Serge E. Hallyn
2005-12-07 22:31           ` Dave Hansen
2005-12-07 22:51             ` Eric W. Biederman
2005-12-08  5:42             ` Jeff Dike
2005-12-08 10:09             ` Andi Kleen
2005-12-07 22:17       ` Cedric Le Goater
  -- strict thread matches above, loose matches on Subject: below --
2005-11-16  2:24 Hua Zhong (hzhong)
2005-11-16 17:52 ` Bernard Blackham

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox