[CRIU] [RFC] FSTYPE__UNSUPPORTED/AUTO && non-virtual filesystems

[Pavel Emelyanov]

On 03/31/2015 02:53 PM, Oleg Nesterov wrote:
> Pavel,
> 
> Our discussion with Christopher was a bit confusing and off-topic.
> Could you please comment this hack? I mostly mean the problem, not
> the change itself.
> 
> Please ignore the note about --ignore-this-mountpoint, this is
> another thing.

Ah, that's different thing. Sorry, I've mixed it with the rest of
the set :(

Yes, the mountpoints with "real" source are currently not supported by
CRIU. With the current proposal of adding "trusted fstypes" with CLI
option I think that we can relax the whole devices checks and just
return the source from image file for FSTYPE__AUTO mounts.

The justification for this is quite simple. Regardless of whether devices
match or not we're doing a mount that user can both -- screw up or make
right. Even if device number match, the "real" device can be anything.
If device numbers do not match this can be valid case -- maybe user just
replaced the disk with its replica. So from my perspective for the __AUTO
mountpoints we can just return back the original source.

I would say that for any classic on-disk filesystem we can do this.

-- Pavel

> On 03/28, Oleg Nesterov wrote:
>>
>> On 03/27, Oleg Nesterov wrote:
>>>
>>> I tried to dump/restore the dummy (/bin/sleep actually) application
>>> running in unshared mnt namespace. Dump/Restore fails because a lot
>>> of filesystems are FSTYPE__UNSUPPORTED: xfs, hugetlbfs, autofs, configfs,
>>> selinuxfs.
>>>
>>> OK, lets forget about xfs for the moment.
>>
>> Now lets return to xfs.
>>
>> It is FSTYPE__UNSUPPORTED too, and restore obviously fails even if I
>> turn it into FSTYPE__AUTO via command line. Because resolve_source()
>> insists on kdev_major() == 0.
>>
>> Can't we relax this check? Just try to use mi->source "optimistically" ?
>> At least for FSTYPE__AUTO ?
>>
>> I understand that the patch below is not what we really want. And I
>> have to admit that I do not really understand all implications. But
>> perhaps something like this simple make sense anyway? Again, if the
>> user does (say) "--xxx xfs" he should know what it does...
>>
>> With this hack I can finally dump/restore the application running with
>> unshared mnt ns on rhel-7 without unmounting /boot.
>>
>> BUT. This makes me think again that we do want --ignore-this-mountpoint
>> option. Why not? And afaics trivial to implement. Of course, this will
>> be "use at your own risk" too.
>>
>> Oleg.
>>
>> --- a/mount.c
>> +++ b/mount.c
>> @@ -1392,6 +1392,15 @@ static char *resolve_source(struct mount_info *mi)
>>  		 */
>>  		return mi->source;
>>  
>> +	if (mi->fstype->code == FSTYPE__AUTO) {
>> +		struct stat st;
>> +
>> +		if (!stat(mi->source, &st) && S_ISBLK(st.st_mode) &&
>> +		    major(st.st_rdev) == kdev_major(mi->s_dev) &&
>> +		    minor(st.st_rdev) == kdev_minor(mi->s_dev))
>> +			return mi->source;
>> +	}
>> +
>>  	pr_err("No device for %s mount\n", mi->mountpoint);
>>  	return NULL;
>>  }
> 
> .
>