On 21/02/11 12:40 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [louis.rill...@kerlabs.com] wrote:
> | > But in 2.6.32 i.e RHEL5, tsk->signal is set to NULL in __exit_signal().
> | > So, I am trying to rule out the following scenario:
> | >
> | &g
here else before current
has passed __exit_signal().
By the way, instead of checking current->parent->signal,
current->parent->exit_state would look cleaner to me. current->parent is not
supposed to wait on ->wait_chldexit after calling do_exit(), right?
Louis
--
On 10/02/11 9:54 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [louis.rill...@kerlabs.com] wrote:
> | > I can reproduce a crash with 2.6.32 - where if container-init terminates
> | > before a detached child, we get a crash when the detached child calls
> | > proc_flush_
On 09/02/11 11:02 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [louis.rill...@kerlabs.com] wrote:
> | > | Are we still getting it with 2.6.37 ?
> | >
> | > I am not currently getting the crash on 2.6.37 - I thought it was due to
> | > the following commit
Oops, failed to add Eric properly in Cc...
Louis
On 09/02/11 13:35 +0100, Louis Rilling wrote:
> On 09/02/11 7:18 -0500, Oren Laadan wrote:
> >
> >
> > On 02/09/2011 07:01 AM, Louis Rilling wrote:
> > > On 08/02/11 18:09 -0800, Sukadev Bhattiprolu
On 09/02/11 7:18 -0500, Oren Laadan wrote:
>
>
> On 02/09/2011 07:01 AM, Louis Rilling wrote:
> > On 08/02/11 18:09 -0800, Sukadev Bhattiprolu wrote:
> >> Oren Laadan [or...@cs.columbia.edu] wrote:
> >> |
> >> |
> >> | On 02/05/2011 04:40
; Author: Oleg Nesterov
> Date: Thu Dec 17 15:27:15 2009 -0800
I don't think that this introduced the bug. The bug triggers with EXIT_DEAD
tasks, for which wait() must ignore (see below). So, the bug looks still there
in 2.6.37.
>
> But if that is true, I need to investigate
irect
> the output of the app to 'sort' right ? So expecting the user to
> redo the redirection on restart would treat both redirections ('>'
> and '|') in a consistent way ?
From the fd substitution point of view, this means that lxc-restart would
automat
.get= netns_get,
> + .put= netns_put,
> + .install= netns_install,
> +};
> +#endif
> --
> 1.6.5.2.143.g8cc62
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
On 09/09/10 4:02 -0700, Matt Helsley wrote:
> On Thu, Sep 09, 2010 at 12:37:20PM +0200, Louis Rilling wrote:
> > On 08/09/10 21:06 -0700, Matt Helsley wrote:
> > > On Wed, Sep 08, 2010 at 08:03:52PM -0500, Serge E. Hallyn wrote:
> > > > Quoting Matt Helsley (matth...
too.
>
> > If so, then having a fcntl flag (and later madvise) makes sense.
> > But if we're going to add options to various different APIS which
> > really are all only useful for c/r, then maybe a single new cr_advise()
> > really does make sense. The alt
On 08/09/10 12:00 +0200, Greg Kurz wrote:
> On Wed, 2010-09-08 at 10:41 +0200, Louis Rilling wrote:
> > Both of those mechanisms have been developed in Kerrighed, and Matthieu (in
> > Cc)
> > should start a discussion about this in the next weeks.
> >
>
> Matth
means that the checkpoint could record that a given
file descriptor was shared by some files_struct, but the file descriptor itself
is not checkpointed because of various reasons, like file descriptor outside
the container, unsupported file systems, etc.
Both of those mechanisms
st from
> lmbench.
This patch looks like it is working (only a small RCU issue shown below). I
couldn't try it yet though.
I must admit that I am using a similar back-off solution in Kerrighed (not to
solve the issue of proc_flush_task(), but for one of the reasons that you st
ked for and, if possible, mntget() at release_task()-time.
Could you elaborate on the trade-off, that is accessing proc_mnt at
copy_process()-time vs looking up proc_mnt at release_task()-time?
Thanks,
Louis
>
> Reported-by: Louis Rilling
> Signed-off-by: Eric W. Biederman
> ---
>
On 09/07/10 6:05 -0700, Eric W. Biederman wrote:
> Louis Rilling writes:
>
> > On 08/07/10 21:39 -0700, Eric W. Biederman wrote:
> >>
> >> Currently it is possible to put proc_mnt before we have flushed the
> >> last process that will use
ace *pid_ns)
> rc = sys_wait4(-1, NULL, __WALL, NULL);
> } while (rc != -ECHILD);
>
> + pid_ns_release_proc(pid_ns);
> acct_exit_ns(pid_ns);
> return;
> }
> --
> 1.6.5.2.143.g8cc62
>
> --
> To unsubscribe from this list:
On 24/06/10 21:18 +0200, Oleg Nesterov wrote:
> On 06/24, Louis Rilling wrote:
> >
> > [ Resending because of buggy quotes in Eric's address. Sorry for the noise.
> > ]
> >
> > On 06/19, Oleg Nesterov wrote:
> > > And the last one on top of this
task() when the
last pid is detached.
This solves the EXIT_DEAD tasks issue for the same reason.
Signed-off-by: Louis Rilling
---
fs/proc/base.c|4
fs/proc/root.c| 11 ++-
include/linux/pid_namespace.h |3 +++
kernel/fork.c
() in copy_process() cleanup path, since
free_pid() is called to cleanup alloc_pid().
This solves the multi-threaded init doing exec issue, since all
sub-threads including former leader have called proc_flush_task() when the
last pid is detached.
This solves the EXIT_DEAD tasks issue for the sam
On 21/06/10 5:58 -0700, Eric W. Biederman wrote:
> Louis Rilling writes:
>
> > On 18/06/10 18:27 +0200, Oleg Nesterov wrote:
> >> On 06/18, Louis Rilling wrote:
> >> >
> >> > On 17/06/10 23:36 +0200, Oleg Nesterov wrote:
> >> > > On 06
On 18/06/10 19:55 +0200, Oleg Nesterov wrote:
> On 06/18, Louis Rilling wrote:
> >
> > On 18/06/10 18:08 +0200, Oleg Nesterov wrote:
> > >
> > > Not sure I ever understood this code. Certainly I can't say I understand
> > > it now. Still, do we real
On 18/06/10 18:27 +0200, Oleg Nesterov wrote:
> On 06/18, Louis Rilling wrote:
> >
> > On 17/06/10 23:36 +0200, Oleg Nesterov wrote:
> > > On 06/17, Eric W. Biederman wrote:
> > > >
> > > > The task->children isn't changed until __u
On 18/06/10 19:55 +0200, Oleg Nesterov wrote:
> On 06/18, Louis Rilling wrote:
> > > @@ -74,7 +74,7 @@ static int proc_get_sb(struct file_syste
> > > ei = PROC_I(sb->s_root->d_inode);
> > > if (!ei->pid) {
> > >
On 18/06/10 18:08 +0200, Oleg Nesterov wrote:
> On 06/18, Oleg Nesterov wrote:
> >
> > On 06/18, Louis Rilling wrote:
> > >
> > > On 17/06/10 23:20 +0200, Oleg Nesterov wrote:
> > > > On 06/16, Louis Rilling wrote:
> > > > >
&
s empty.
Not sure about the performance impact though. Maybe some WAIT_NO_CHILDREN flag
in parent->signal could limit it. But if EXIT_DEAD children are removed from
->children before release_task(), I'm afraid that this becomes impossible.
Thanks,
Louis
--
Dr Louis Rilling
On 17/06/10 23:20 +0200, Oleg Nesterov wrote:
> On 06/16, Louis Rilling wrote:
> >
> > Detached tasks are not seen by zap_pid_ns_processes()->sys_wait4(), so
> > that release_task()->proc_flush_task() of container init can be called
> > before it is for som
On Thu, Jun 17, 2010 at 06:41:49AM -0700, Eric W. Biederman wrote:
> Pavel Emelyanov writes:
>
> > On 06/16/2010 08:34 PM, Louis Rilling wrote:
> >> [ Resending, hopefully with all pieces ]
> >>
> >> Detached tasks are not seen by zap_pid_ns_processes()-
_flush_task() becomes safe
whatever the ordering of tasks.
Signed-off-by: Louis Rilling
---
fs/proc/base.c | 18 ++
include/linux/proc_fs.h |4
kernel/fork.c |1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/
= task_pid(task);
> > + for (i = 0; i <= pid->level; i++)
> > + mntget(pid->numbers[i].ns->proc_mnt);
>
> I feel I'm missing something significant, but this patch breaks
> the mntget/mntput balance. Doesn't it?
Why?
all mntget() here have their
ng. Will resend ASAP.
Thanks,
Louis
>
> > +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the
ordering of tasks.
Signed-off-by: Louis Rilling
---
fs/proc/base.c | 17 +
include/linux/proc_fs.h |4
kernel/fork.c |1 +
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index acb7ef8..4d7328f 1006
On 23/03/10 8:52 -0500, Serge E. Hallyn wrote:
> Quoting Louis Rilling (louis.rill...@kerlabs.com):
>
> Hi Louis, thanks again for reviewing.
No problem, thanks to you for your patience.
>
> > To me the real reason is to anticipate pid namespace unsharing. And this
>
*/
> + __s32 rpid;
> + __s32 depth; /* pid namespace depth relative to container init */
> +} __attribute__((aligned(8)));
> +
> +/* number of vpids */
> +struct ckpt_hdr_vpids {
> + struct ckpt_hdr h;
> + __s32 nr_vpids;
> } __attribute__
On Mon, Mar 22, 2010 at 12:57:35PM -0700, Matt Helsley wrote:
> On Mon, Mar 22, 2010 at 09:38:00AM -0500, Serge E. Hallyn wrote:
> > Quoting Louis Rilling (louis.rill...@kerlabs.com):
> > > On Fri, Mar 19, 2010 at 04:39:55PM -0500, Serge E. Hallyn wrote:
> > > > Sup
IDS_CHUNK - hidx + vidx;
if (vidx == 0)
task_pidns = active_pidns;
for (; vidx < nsdelta; vidx++) {
h[hidx].pid = task_pid_nr_ns(task, task_pidns);
hidx++;
&msg, &kvec, 1, kvec.iov_len);
> + if (ret < 0)
> + goto out;
> + else if (ret != skb->len) {
> + ret = -EIO;
> + goto out;
> + }
> +
> + /* Free the send skb to make room for the receive skb */
> + kfree(s
On 04/12/09 8:21 -0800, Dave Hansen wrote:
> On Fri, 2009-12-04 at 17:08 +0100, Louis Rilling wrote:
> > On 04/12/09 8:05 -0800, Dave Hansen wrote:
> > > > syscall also destroys r11, so it should be added to the clobber list.
> > >
> > > Even though it
On 04/12/09 8:05 -0800, Dave Hansen wrote:
> > syscall also destroys r11, so it should be added to the clobber list.
>
> Even though it is a ptregscall?
The assembly instruction itself destroys r11 (same for rcx).
Thanks,
Louis
--
Dr Louis RillingK
obber list.
Libc also adds "cc" to the clobber list. I'm not sure that this matters though.
So the result could be:
:"rcx", "r10", "r11", "cc"
Thanks,
Louis
> );
>
> if (retval < 0) {
> errno = -retval;
>
printf("I read the text: %s\n", input);
> return 0;
> }
>
> -serge
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
--
Dr Louis
On 19/11/09 22:44 +0100, Louis Rilling wrote:
> On Thu, Nov 19, 2009 at 01:32:36PM -0800, Dave Hansen wrote:
> > On Thu, 2009-11-19 at 22:26 +0100, Louis Rilling wrote:
> > > But actually this is even better :D:
> > >
> > > __asm__ __volatile__(
>
On 19/11/09 23:29 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [louis.rill...@kerlabs.com] wrote:
> | >
> | > __asm__ __volatile__(
> | > "syscall\n\t" /* Linux/x86_64 system call */
> | > "t
On Thu, Nov 19, 2009 at 01:32:36PM -0800, Dave Hansen wrote:
> On Thu, 2009-11-19 at 22:26 +0100, Louis Rilling wrote:
> > But actually this is even better :D:
> >
> > __asm__ __volatile__(
> > "movq %3, %%r
On Thu, Nov 19, 2009 at 10:26:46PM +0100, Louis Rilling wrote:
> On Thu, Nov 19, 2009 at 09:48:49AM -0800, Dave Hansen wrote:
> > On Thu, 2009-11-19 at 10:58 +0100, Louis Rilling wrote:
> > > > int clone_with_pids(long flags_low, struct clone_args *clone_args, lo
On Thu, Nov 19, 2009 at 09:48:49AM -0800, Dave Hansen wrote:
> On Thu, 2009-11-19 at 10:58 +0100, Louis Rilling wrote:
> > > int clone_with_pids(long flags_low, struct clone_args *clone_args, long
> > > args_size,
> > > int *pids)
>
cx, r8 and r9 should be added to the clobber list because of
the call to the subthread function.
7. rsi could be used in place of rbx to hold the function pointer, which would
allow you to remove ebx from the clobber list.
8. I don't see why rbp should be saved. The ABI says it must b
On 25/09/09 10:23 +0200, Louis Rilling wrote:
> On Thu, Sep 24, 2009 at 11:43:59PM +0200, Arnd Bergmann wrote:
> > On Thursday 24 September 2009, Sukadev Bhattiprolu wrote:
> > > +asmlinkage long
> > > +sys_clone2(struct clone_struct __user *ucs, pid_t __user *pids)
&g
y usable by the nine
> architectures
> implementing that. The other architectures can then decide between adding
> their private version of sys_clone2 with an open-coded user_stack_pointer
> implementation or alternatively implement the tracehooks.
It will very likely break ia64, whic
ers. In case of clone(), this is
> the user stack pointer.
AFAICS clone() actually needs _all_ registers (see x86 copy_thread() for
instance). Any variant of clone() will have this requirement.
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatimen
On 08/09/09 9:19 -0400, Oren Laadan wrote:
>
>
> Louis Rilling wrote:
> > On 04/09/09 10:26 -0500, Serge E. Hallyn wrote:
> >> Quoting Oren Laadan (or...@librato.com):
> >>> During restart, we need to allocate pty slaves with the same
> >>> ident
trl_lock, flags);
>
> - /* Account for the p->signal references we killed */
> + /* Account
> +
> + for the p->signal references we killed */
> while (refs--)
> tty_kref_put(tty);
>
Nit: this hunk is certainly not needed ;)
[.
ll, but still ...
Moreover I see no reason whey there would be no way to refactorize ptmx code and
have less duplicated code with the ptmx_create() approach.
Thanks,
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatiment Germanium
Phone: (+33|0)
On 14/08/09 18:07 -0400, Oren Laadan wrote:
> Version 3 of pending signals c/r addresses previous comments.
> Changes:
>
> - [Louis Rilling] Fix saving of signal->it_real_incr if not expired
> - Fix restoring of signal->it_real_incr if expire is zero
> - Save virt/prof ex
On 06/08/09 4:40 -0700, Paul Menage wrote:
> On Thu, Aug 6, 2009 at 4:24 AM, Louis Rilling
> wrote:
> >
> > You meant signal_struct, right? sighand_struct can be shared by several
> > thread groups, while signal_struct can't.
> >
>
> No, I meant sighand_
On 06/08/09 3:28 -0700, Paul Menage wrote:
> On Thu, Aug 6, 2009 at 2:58 AM, Louis Rilling
> wrote:
> >
> > mutex_lock_nested is not enough, since this would require putting each
> > thread's
> > mutex in a different class. Again, something like mutex_l
On 06/08/09 11:58 +0200, Louis Rilling wrote:
> On 05/08/09 17:01 -0700, Benjamin Blum wrote:
> > On Wed, Aug 5, 2009 at 9:42 AM, Louis Rilling
> > wrote:
> > > On 05/08/09 9:11 -0700, Paul Menage wrote:
> > >> On Wed, Aug 5, 2009 at 3:20 AM, Louis Rilling
On 05/08/09 17:01 -0700, Benjamin Blum wrote:
> On Wed, Aug 5, 2009 at 9:42 AM, Louis Rilling
> wrote:
> > On 05/08/09 9:11 -0700, Paul Menage wrote:
> >> On Wed, Aug 5, 2009 at 3:20 AM, Louis Rilling
> >> wrote:
> >> >
> >> > The dow
On 05/08/09 9:11 -0700, Paul Menage wrote:
> On Wed, Aug 5, 2009 at 3:20 AM, Louis Rilling
> wrote:
> >
> > The downside of this is teaching lockdep about this recursive locking. Not
> > that
> > simple actually...
>
> Don't we just give each thread&#x
On 04/08/09 14:43 -0400, Oren Laadan wrote:
>
>
> Louis Rilling wrote:
> > Hi Oren,
> >
> > On 04/08/09 5:09 -0400, Oren Laadan wrote:
> >> This patch adds support for real/virt/prof itimers.
> >> Expiry and the interval values are both saved
ist_lock);
The downside of this is teaching lockdep about this recursive locking. Not that
simple actually... so that such cases are currently handled using a higher-level
lock that prevents races in locking the whole chain (there was one such example
for locking all vmas with KVM). IIUC, the
heckpoint_hdr.h b/include/linux/checkpoint_hdr.h
> index 9dcb160..a0ec25f 100644
> --- a/include/linux/checkpoint_hdr.h
> +++ b/include/linux/checkpoint_hdr.h
> @@ -472,6 +472,12 @@ struct ckpt_hdr_rlimit {
> struct ckpt_hdr_signal {
> struct ckpt_hdr h;
> str
On 28/07/09 17:23 -0700, Benjamin Blum wrote:
> On Fri, Jul 24, 2009 at 2:52 PM, Benjamin Blum wrote:
> > On Fri, Jul 24, 2009 at 3:02 AM, Louis Rilling
> > wrote:
> >> On 23/07/09 20:22 -0700, Ben Blum wrote:
> >>> @@ -408,6 +409,15 @@ You can attach
y new unique css_set),
> we know that once we've run through all the threads in the
> thread_group and verified that we have the appropriate pre-fetched
> css_set objects for all of them, it doesn't matter if any new threads
> are created - they'll share one of th
nr_pending++;
> + h = ckpt_hdr_get_type(ctx, nr_pending * sizeof(*si) + sizeof(*h),
> + CKPT_HDR_SIGPENDING);
> + if (!h)
> + return -ENOMEM;
> +
> + h->nr_pending = nr_pending;
> + fill_sigset(&h->signal, &
ree(q);
> + break;
> + }
> +
> + list_add_tail(&pending->list, &q->list);
> + }
> +
> + if (ret < 0) {
> + list_for_each_entry_safe(q, n, &pending->list, list) {
> +
On 24/07/09 12:02 +0200, Louis Rilling wrote:
> Hi Ben,
>
> On 23/07/09 20:22 -0700, Ben Blum wrote:
> > Makes procs file writable to move all threads by tgid at once
> >
> > This patch adds functionality that enables users to move all threads in a
> > threadgro
task_unlock(child);
> write_unlock(&css_set_lock);
> }
> + up_read(&cgroup_fork_mutex);
> }
> /**
> * cgroup_exit - detach cgroup from exiting task
> @@ -3302,6 +3620,24 @@ void cgroup_exit(struct task_struct *tsk, int
> run_ca
t, *res = NULL;
> + for_each_root(root) {
> + if (root->subsys_bits && (1UL << id)) {
Should be &, not && --^^
Louis
> + BUG_ON(res);
> + res = root;
> +
On Thu, Jul 02, 2009 at 01:19:30AM -0700, Paul Menage wrote:
> On Thu, Jul 2, 2009 at 1:09 AM, Louis Rilling
> wrote:
> >
> > I did not see anything preventing two hierarchies from having the same
> > (non empty) name.
>
> If you try to mount with a name th
free_cg_links(&tmp_cg_links);
> + goto drop_new_super;
> }
>
> /* EBUSY should be the only error here */
> @@ -1146,12 +1178,17 @@ static int cgroup_get_sb(struct file_system_type
> *fs_type,
> }
>
> simple
ERR_PTR(ret);
> +
> + if (h->family == AF_UNIX) {
> + ret = sock_un_restart(ctx, h, socket);
> + ckpt_debug("sock_un_restart: %i\n", ret);
> + } else {
> + ckpt_debug("unsupported family %i\n", h->family);
On 05/05/09 8:49 -0500, Serge E. Hallyn wrote:
> Quoting Louis Rilling (louis.rill...@kerlabs.com):
> > On 04/05/09 8:01 -0500, Serge E. Hallyn wrote:
> > > Quoting Oren Laadan (or...@cs.columbia.edu):
> > > > > I see one drawback with this ap
IPC
objects, and the application still uses them. Moreover, on restart the
administrator should be able to first install the required IPC objects, e.g.
re-create them from scratch, or restore them from another checkpoint, and second
restart the application, linking it to the pr
On 29/04/09 18:47 -0400, Oren Laadan wrote:
> Hi Louis,
>
> Louis Rilling wrote:
> > Hi,
> >
> > On 28/04/09 19:23 -0400, Oren Laadan wrote:
> >> Here is the latest and greatest of checkpoint/restart (c/r) patchset.
> >> The logic and image fo
at the process uses. Any changes
> in this blob's format between kernel revisions can be handled by
> an in-userspace conversion program.
>
> This is a similar approach to virtually all of the commercial
> checkpoint/restart products out there, as well as the resea
done from the checkpoint callback setting up an
application-defined signal handler.
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatiment Germanium
Phone: (+33|0) 6 80 89 08 2380 avenue des Buttes de Coesmes
http://www.kerlabs.c
e line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Dr Louis RillingKerlabs
Skype: louis.rilling
On Thu, Oct 30, 2008 at 02:32:51PM -0400, Oren Laadan wrote:
>
>
> Louis Rilling wrote:
> > On Thu, Oct 30, 2008 at 01:45:25PM -0400, Oren Laadan wrote:
> >>
> >> Louis Rilling wrote:
> >>> In Kerrighed this is kernel-based, and will remain kernel-ba
ementations appeared.
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatiment Germanium
Phone: (+33|0) 6 80 89 08 2380 avenue des Buttes de Coesmes
http://www.kerlabs.com/ 35700 Rennes
signature.asc
Description: Digita
On Thu, Oct 30, 2008 at 01:45:25PM -0400, Oren Laadan wrote:
>
>
> Louis Rilling wrote:
> > In Kerrighed this is kernel-based, and will remain kernel-based because we
> > checkpoint a distributed task tree, and want to restart it as mush as
> > possible
> >
On Thu, Oct 30, 2008 at 10:08:44AM -0700, Dave Hansen wrote:
> On Thu, 2008-10-30 at 12:47 +0100, Louis Rilling wrote:
> > 1) this prevents userspace from doing weird things, like changing the task
> > tree
> > and let the kernel detect it and deal with the mess this crea
at the kernel must check for such weird things anyway.
2) restart will be more efficient with respect to shared objects.
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatiment Germanium
Phone: (+33|0) 6 80 89 08 2380 avenue des Buttes
On Wed, Oct 22, 2008 at 12:06:19PM +0200, Greg Kurz wrote:
> On Wed, 2008-10-22 at 11:25 +0200, Louis Rilling wrote:
> > Do you checkpoint uninterruptible syscalls as well? If only interruptible
> > syscalls are checkpointed, I'd say that either this syscall uses
On Wed, Oct 22, 2008 at 02:12:12PM +0400, Andrey Mirkin wrote:
> On Wednesday 22 October 2008 13:25 Louis Rilling wrote:
> > On Wed, Oct 22, 2008 at 12:49:54PM +0400, Andrey Mirkin wrote:
> > > On Monday 20 October 2008 13:23 Cedric Le Goater wrote:
> > > > Hello A
hset which restarts a syscall, but later I plan to add it.
> In OpenVZ checkpointing we restart syscalls if process was caught in syscall
> during checkpointing.
Do you checkpoint uninterruptible syscalls as well? If only interruptible
syscalls are checkpointed, I'd say that eit
t_object(CPT_OBJ_TASK, ti, sizeof(*ti), ctx);
> + if (!err)
> + err = rst_restore_task_struct(current, ti, ctx);
> + /* Restore mm here */
> + if (!err)
> + err = rst_restore_fpustate(current, ti, ctx);
> + if (!err)
> + err = rst_r
mutex_unlock(&mm->context.lock);
> + }
> +#endif
> + return 0;
> +}
> +
> +int cpt_dump_mm(struct task_struct *tsk, struct cpt_context *ctx)
> +{
> + struct mm_struct *mm = tsk->mm;
> + struct cpt_mm_image *v;
> + struct vm_area_
he same questions with respect to Andrey's
patchset?
I'm afraid that we are forgetting to take the best from both approaches...
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBatiment Germanium
Phone: (+33|0) 6 80 89 08 23
->bx;
> + ri.cpt_cx = pt_regs->cx;
> + ri.cpt_dx = pt_regs->dx;
> + ri.cpt_si = pt_regs->si;
> + ri.cpt_di = pt_regs->di;
> + ri.cpt_bp = pt_regs->bp;
> + ri.cpt_ax = pt_regs->ax;
> + ri.cpt_ds = encode_segment(pt_regs->ds);
gt; + }
> + goto repeat;
fdlist = krealloc(fdlist, max, GFP_KERNEL)?
Sorry, I should have suggested this in my first review.
Louis
> + }
> + fdlist[n++] = i;
> + }
> + }
&
> + return -ENOMEM;
> + head = kzalloc(CR_OBJHASH_TOTAL * sizeof(*head), GFP_KERNEL);
512 entries allocated
> + if (!head) {
> + kfree(objhash);
> + return -ENOMEM;
> + }
> +
> + objhash->head = head;
t_code, exit_signal;
64bits alignment issue?
I probably missed it in previous versions...
Louis
> +
> + __u64 utime, stime, utimescaled, stimescaled;
> + __u64 gtime;
> + __u64 prev_utime, prev_stime;
> + __u64 nvcsw, nivcsw;
> + __u64 start_time_sec,
id_vnr(current), current->mm);
> +
> + module_put(THIS_MODULE);
Where is the module ref count dropped in case of success?
> + complete_and_exit(NULL, 0);
> + return 0;
> +}
> +static int create_root_task(struct cpt_context *ctx,
> + struct
size = mm->context.size * LDT_ENTRY_SIZE;
> +
> + ctx->write(mm->context.ldt, size, ctx);
> +
> + mutex_unlock(&mm->context.lock);
> + }
> +#endif
> + return 0;
> +}
> +
> +int cpt_dump_mm(struct task_struct *tsk, struc
On Wed, Sep 03, 2008 at 03:49:51PM +0200, Louis Rilling wrote:
> On Wed, Sep 03, 2008 at 02:57:47PM +0400, Andrey Mirkin wrote:
> > This patchset introduces kernel based checkpointing/restart as it is
> > implemented in OpenVZ project. This patchset has limited functionality and
t */
> + __u32 cpt_hdrlen; /* Size of header */
> + __u16 cpt_content;/* Content type: array, reference... */
This layout looks a bit awkward for 32bits/64bits compatibility. Maybe put
cpt_hdrlen before cpt_type?
Louis
--
Dr Louis Rilling
patches to make review more easier.
Thank you Andrey for having highlighted the differences with Oren's approach,
and for having split this patchset. Few remarks in reply to the patches.
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBati
On Wed, Aug 27, 2008 at 08:41:36AM -0700, Dave Hansen wrote:
>
> Dang. What's the thing we return from system calls that are
> unsupported? Did I just dream that up?
ENOSYS?
Louis
--
Dr Louis RillingKerlabs
Skype: louis.rillingBati
On Tue, Aug 26, 2008 at 10:01:04AM -0700, Dave Hansen wrote:
> On Thu, 2008-08-21 at 12:40 +0200, Louis Rilling wrote:
> >
> > > +struct cr_objhash {
> > > + struct cr_obj **hash;
> > > + int next_tag;
> > > +};
> > > +
>
1 - 100 of 118 matches
Mail list logo
