[Devel] Re: [RFC][PATCH 00/11] track files for checkpointability

[Serge E. Hallyn]

Quoting Nathan Lynch (ntl at pobox.com):
> "Serge E. Hallyn" <serue at us.ibm.com> wrote:
> > Quoting Nathan Lynch (ntl at pobox.com):
> > > Please consider this and a following patch.
> > > 
> > > >From a0fb96aa41c4d360559013cfd7f32f07f449c1c4 Mon Sep 17 00:00:00 2001
> > > From: Nathan Lynch <ntl at pobox.com>
> > > Date: Mon, 9 Mar 2009 22:23:02 -0500
> > > Subject: [PATCH] checkpoint: make files_deny_checkpointing print task name and pid
> > > 
> > > This lets the developer know *which* task performed an action that
> > > prevents checkpoint.
> > > 
> > > 
> > > Signed-off-by: Nathan Lynch <ntl at pobox.com>
> > > ---
> > >  fs/file.c                  |    2 +-
> > >  fs/open.c                  |    2 +-
> > >  include/linux/checkpoint.h |   13 +++++++------
> > >  3 files changed, 9 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/fs/file.c b/fs/file.c
> > > index 0501af6..fcb2803 100644
> > > --- a/fs/file.c
> > > +++ b/fs/file.c
> > > @@ -299,7 +299,7 @@ static void __scan_files_for_cr(struct files_struct *files)
> > >  			continue;
> > >  		if (cr_file_supported(f))
> > >  			continue;
> > > -		files_deny_checkpointing(files);
> > > +		files_deny_checkpointing(current, files);
> > 
> > Ah but you can't do this, because __scan_files_for_cr is called
> > from dupfd which is called during copy_files, right?
> 
> Are you saying that the message should identify the child instead of
> the parent as the uncheckpointable task?

Yes.  The parent may have opened the fd (or, importantly, may NOT have)
but the child is the one now getting that 'dirty' fd and being newly
marked uncheckpointable.

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers