[CRIU] [PATCH] flock: blocked processes are not interesting for us

[Andrew Vagin]

On Wed, Nov 05, 2014 at 03:40:03PM +0400, Pavel Emelyanov wrote:
> On 10/31/2014 02:42 PM, Andrey Vagin wrote:
> > All out processes are stopped in a moment, when file locks are
> > collected, so they can't to wait any locks.
> > 
> > Here is a proof of this theory:
> > [root at avagin-fc19-cr ~]# flock xxx sleep 1000 &
> > [1] 23278
> > [root at avagin-fc19-cr ~]# flock xxx sleep 1000 &
> > [2] 23280
> > [root at avagin-fc19-cr ~]# cat /proc/locks
> > 1: FLOCK  ADVISORY  WRITE 23278 08:03:280001 0 EOF
> > 1: -> FLOCK  ADVISORY  WRITE 23280 08:03:280001 0 EOF
> > [root at avagin-fc19-cr ~]# gdb -p 23280
> > (gdb) ^Z
> > [3]+  Stopped                 gdb -p 23280
> > [root at avagin-fc19-cr ~]# cat /proc/locks
> > 1: FLOCK  ADVISORY  WRITE 23278 08:03:280001 0 EOF
> > 
> > Currently criu can dump nothing, if we have one process which is
> > waiting a lock. I don't see any reason to do this.
> > 
> > Cc: Qiang Huang <h.huangqiang at huawei.com>
> > Reported-by: Mr Jenkins
> > Signed-off-by: Andrey Vagin <avagin at openvz.org>
> > ---
> >  proc_parse.c | 36 ++++++++++++++++--------------------
> >  1 file changed, 16 insertions(+), 20 deletions(-)
> > 
> > diff --git a/proc_parse.c b/proc_parse.c
> > index 389cb72..b1afb61 100644
> > --- a/proc_parse.c
> > +++ b/proc_parse.c
> > @@ -1501,6 +1501,12 @@ int parse_file_locks(void)
> >  			goto err;
> >  		}
> >  
> > +		pr_info("lockinfo: %lld:%d %x %d %02x:%02x:%ld %lld %s\n",
> > +			fl->fl_id, fl->fl_kind, fl->fl_ltype,
> > +			fl->fl_owner, fl->maj, fl->min, fl->i_no,
> > +			fl->start, fl->end);
> > +
> > +
> >  		if (fl->fl_kind == FL_UNKNOWN) {
> >  			pr_err("Unknown file lock!\n");
> >  			ret = -1;
> > @@ -1508,6 +1514,16 @@ int parse_file_locks(void)
> >  			goto err;
> >  		}
> >  
> > +		if (is_blocked) {
> > +			/*
> > +			 * All target processes are stopped in this moment and
> > +			 * can't wait any locks.
> > +			 */
> > +			pr_debug("Skip blocked processes\n");
> > +			xfree(fl);
> > +			goto err;
> 
> Why goto err? I thought the intention is to just skip those.

You are right. Thanks.

> 
> > +		}
> > +
> >  		if ((fl->fl_kind == FL_POSIX) &&
> >  				!pid_in_pstree(fl->fl_owner)) {
> >  			/*
> > @@ -1519,26 +1535,6 @@ int parse_file_locks(void)
> >  			continue;
> >  		}
> >  
> > -		pr_info("lockinfo: %lld:%d %x %d %02x:%02x:%ld %lld %s\n",
> > -			fl->fl_id, fl->fl_kind, fl->fl_ltype,
> > -			fl->fl_owner, fl->maj, fl->min, fl->i_no,
> > -			fl->start, fl->end);
> > -
> > -		if (is_blocked) {
> > -			/*
> > -			 * Here the task is in the pstree.
> > -			 * If it is blocked on a flock, when we try to
> > -			 * ptrace-seize it, the kernel will unblock task
> > -			 * from flock and will stop it in another place.
> > -			 * So in dumping, a blocked file lock should never
> > -			 * be here.
> > -			 */
> > -			pr_perror("We have a blocked file lock!");
> > -			ret = -1;
> > -			xfree(fl);
> > -			goto err;
> > -		}
> > -
> >  		list_add_tail(&fl->list, &file_lock_list);
> >  	}
> >  
> > 
>