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

[Christopher Covington]

Hi Oleg,

On 03/30/2015 01:41 PM, Oleg Nesterov wrote:
> On 03/30, Christopher Covington wrote:
>>
>> On 03/30/2015 11:35 AM, Oleg Nesterov wrote:
>>>
>>> you know I am very-very new to criu/etc, not sure I understand you
>>> correctly...
>>>
>>> On 03/30, Christopher Covington wrote:
>>>>
>>>> Hi Oleg,
>>>>
>>>> On 03/28/2015 02:18 PM, Oleg Nesterov wrote:
>>>>
>>>>> 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.
>>>>
>>>> How hard would it be to unshare the mount namespace, unmount the mountpoint
>>>> you want to ignore, and then dump the checkpoint?
>>>
>>> How can unshare help? Perhaps you mean setns() + umount? But there can be
>>> other processes in the same mnt ns which need this mountpoint?
>>
>> I usually dump very simple process trees in simple environments where this
>> sort of thing can work. It sounds like you have a more sophisticated process
>> tree and environment where it wouldn't work.
> 
> Heh ;) my process tree is the single
> 
> 	perl -e 'close STDIN; close STDOUT; close STDERR; sleep'
> 
> process ;) But it runs in another (non root) mnt namespace. And I am trying
> to dump/restore it from the root namespace.

I need to learn more about how user namespaces constrain things (I couldn't
get unshare -U to work on the first try), but using just a mount namespace and
running as root the whole time I'm able to make a mount disappear with the
following:

$ m="mount | grep -c boot"
$ eval $m; unshare -m -- sh -c "umount boot; $m"; eval $m
1
0
1

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project