[CRIU] [PATCH] fsnotify: Use longest mount point for inotify watchee

Pavel Emelyanov xemul at parallels.com
Mon Oct 12 01:16:50 PDT 2015


On 10/12/2015 11:14 AM, Cyrill Gorcunov wrote:
> On Mon, Oct 12, 2015 at 11:06:32AM +0300, Pavel Emelyanov wrote:
>> On 10/10/2015 11:07 AM, Cyrill Gorcunov wrote:
>>> In debian-8 container we faced the problem -- systemd
>>> creates nested mount namespaces and inotify watchee
>>> are resolved into a path which is inaccessbile on
>>> restore (because we're operating in task's mount
>>> namespace). So here is a dirty hack for now -- choose
>>> the widest mount point as a reference. The proper
>>> fix requires kernel patching.
>>
>> How about Andrey's patch that saved mnt-id for an inotify?
> 
> This won't work on its own. Please look at the second patch
> I send into the reply of this one. We need mnt_id but the
> path may be inaccessible during the restore because the
> restore comes in another mount namespace where the former
> path is no longer accessbile.

But we do know the namespace the path come from, why do we ever
_guess_ anything instead of just going to that ns and opening
the file there?

-- Pavel



More information about the CRIU mailing list