[CRIU] [PATCH 1/2] mount: Use path resolving to find mount points

[Cyrill Gorcunov]

On Fri, Dec 06, 2013 at 02:39:37PM +0400, Pavel Emelyanov wrote:
> > @@ -270,7 +270,7 @@ struct file_remap *lookup_ghost_remap(u32 dev, u32 ino)
> >  
> >  	mutex_lock(ghost_file_mutex);
> >  	list_for_each_entry(gf, &ghost_files, list) {
> > -		if (phys_stat_dev_match(gf->dev, dev) && gf->ino == ino) {
> > +		if (gf->ino == ino && phys_stat_dev_match(gf->dev, dev, gf->remap.path)) {
> 
> The gf->dev value came from the image. It's the device we _saw_ at dump time.
> Thus we should do the name resolution _then_ and write in the image the phys
> device ID instead of volume id.

Sticktly speaking -- yes, we should. But on the other hands I don't see much point
in it. gf->dev migh be some subvolume and then gf->dev != dev but path-resolve
should find that @dev is subvolume of some mount point where gf->remap.path
is resides. No?

> I don't think this resolve fn is correct. You should do careful tree
> descending looking at paths. Something like below.
> 
> 	mi = root;
> 	sub_path = path;
> next_component:
> 	/* iterate over children mounts and find the beth path match */
> 	list_for_each_entry(ch, &mi->children, siblings) {
> 		len = strlen(ch->mountpoint);
> 		if (strnel(sub_path) < len)
> 			/* the ch point's mountpoint cannot match the subpath */
> 			continue;
> 		if (!strncmp(sub_path, ch->mountpoint, len) {
> 			/* descend and search for the next mount point */
> 			sub_path += len;
> 			mi = ch;
> 			goto next_component;
> 		}
> 	} /* no children match the path -- the current path points to mi */

Yeah, thanks. Need more accurate walkout.

	Cyrill