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

[Pavel Emelyanov]

On 12/06/2013 02:53 PM, Cyrill Gorcunov wrote:
> 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?

No. Currently you may dump tasks on btrfs, them move them to another box with
changed devices. All will work, since on restore we don't stat paths. With your
patch things would break.

>> 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.

OK, thanks.

> 	Cyrill
> .
>