[CRIU] [PATCH 3/5] files: Rework clean_one_remap to order ghost dirs removal

[Pavel Tikhomirov]

On 2/25/19 5:31 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 25, 2019 at 02:20:11PM +0000, Pavel Tikhomirov wrote:
> ...
>>> +
>>> +	/*
>>> +	 * Otherwise simply order by mnt_id order, we just
>>> +	 * can't do anything beter (it is early stage where
>>> +	 * mounts are not yet processed).
>>
>> What exact problem is with different mounts, can you show an example
>> paths? (AFAICS Mount trees are already built at these point)
> 
> Can we have same "paths" under different mounts? I think we can.

AFAICS For now we can't handle open files/directories on overmounted 
mounts. Thus "same paths" will fail on dump in the check in 
dump_one_reg_file which I've recently introduced to protect from wrongly 
restoring such files as ghost-files =)

> Thus we can order only paths which are under same mount

But you are right, when we will support restoring files on overmounted 
mounts we will need something like these.

> And no, at this moment they are not yet constructed.

Mount trees are created in:

restore_task_with_children (for root task)
  prepare_namespace
   prepare_mnt_ns

and we are in:

restore_task_with_children
  root_prepare_chared
   prepare_remaps
    order_remap_dirs

which is called later.

> 
>>>    
>>> -	ret = unlinkat(rmntns_root, remap->rpath, remap->is_dir ? AT_REMOVEDIR : 0);
>>> -	if (ret < 0) {
>>> -		close(rmntns_root);
>>> -		pr_perror("Couldn't unlink remap %s %s", path, remap->rpath);
>>> +	if (remap->is_dir)
>>> +		ret = clean_ghost_dir(rmntns_root, ri);
>>> +	else
>>> +		ret = unlinkat(rmntns_root, remap->rpath, 0);
>>> +
>>> +	if (ret) {
>>> +		pr_perror("Couldn't unlink remap %d %s", rmntns_root, remap->rpath);
>>>    		return -1;
>>>    	}
>>> -	close(rmntns_root);
>>
>> Don't you leak rmntns_root fd here?
> 
> Sharp eyes! Thanks, indeed! Will update.
> 
> 	Cyrill
> 

-- 
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.