[CRIU] [PATCH 0/1] report fd/path if dump_one_reg_file()->lookup_nsid_by_mnt_id() fails

[Pavel Emelyanov]

On 04/21/2015 11:11 PM, Tycho Andersen wrote:
> On Tue, Apr 21, 2015 at 10:05:45PM +0300, Pavel Emelyanov wrote:
>> On 04/21/2015 08:14 PM, Oleg Nesterov wrote:
>>> On 04/21, Pavel Emelyanov wrote:
>>>>
>>>> This is just to make sure I properly track what's going on with mount.c :)
>>>
>>> A bit off-topic, but let me remind about another problem before I forgot...
>>>
>>> 	# unshare -m
>>> 	# perl -e 'sleep'
>>>
>>> Now "criu dump -t `pidof perl`" fails with
>>>
>>> 	Error (files-reg.c:821): Unable to look up the 22 mount
>>> 	Error (cr-dump.c:1580): Dump files (pid: 10822) failed with -1
>>>
>>> So there are 2 problems:
>>>
>>> 	1. The error message is confusing and doesn't help to understand
>>> 	   whats going on.
>>>
>>> 	   "Fixed" by this patch.
>>
>> Thank you :)
>>
>>> 	2. Well, it would be nice to handle this case too.
>>
>> But what's the case? Why the 22nd mount isn't looked-up?
> 
> It's something like the process still has an fd open on a mount
> namespace which it doesn't see any more (because of unshare()).
> Usually happens with stdin/stdout/stderr, because they are opened when
> the program starts, and then unshare() is called but they still point
> to the parent ns.

Ah, indeed :)

>>> 	   Left as an exercise for criu developers.

I have better example to handle.

   fd = open("/foo/bar");
   chroot("/foo/sub");

But anyway, it's a snap, we already have the notion of "external resource",
just need to add another one -- external file path :P

-- Pavel