[CRIU] [PATCH] mnt: Use ns_mountpoint to open a mount point

[Pavel Emelyanov]

On 10/12/2015 01:37 PM, Cyrill Gorcunov wrote:
> On Mon, Oct 12, 2015 at 01:22:03PM +0300, Pavel Emelyanov wrote:
>> On 10/12/2015 01:05 PM, Cyrill Gorcunov wrote:
>>> On Mon, Oct 12, 2015 at 12:56:55PM +0300, Pavel Emelyanov wrote:
>>>> On 10/09/2015 06:59 PM, Cyrill Gorcunov wrote:
>>>>> From: Andrew Vagin <avagin at openvz.org>
>>>>>
>>>>> open_mountpoint helper is called when mount namespace are
>>>>> already restored so we have to use local paths.
>>>>
>>>> 2 questions from my side:
>>>>
>>>> 1. How is this connected with the patch "fsnotify: save mnt_id with path"?
>>>
>>> It's unconnected actually. The Andrew's patch adds mnt_id for tmpfs as far
>>> as I remeeber. But my patch for "guessing" the path (which I'm still
>>> working on) based on this patch. Still note that there mount.c code is
>>> modified as well which is needed to fix debian-8 nested mountnamespace
>>> problems.
>>
>> OK, so that's the 3rd issue fixed by this patch? Let me summarize
>>
>> 1. watch from another namespace (fixed, commiteed)
>> 2. watch from bind mount with weird name (kernel is read for details)
>> 3. this issue
>>
>> Right? If yes, what are the circumstances when we face _this_ one?
> 
> Hmm. Let rather _me_ summarized all the problems.
> 
> 1) We've catched a problem with restoring nested mount namespaces
>    (in particular master/slave relationship) in debian8 container.
>    To fix it Andrew made
> 
> 	mnt: Fix slave mounts order estimation in can_mount_now
> 
> That's first bug and first part of its fix

OK

> 2) Opening mountpoints should be done using @ns_mountpoint as
>    a reference. This is a second part of the bug above fixed.
>    That is _this_ patch.
> 
> Now once mountpoints order and their openup is fixed we faced
> problems with opening watchees in fsnotify code. And here
> two patches which should address it.

Can I see the test that triggers this BUG?

> 3) Andrew's fsnotify: save mnt_id with path (which address
>    tmpfs only)

Tmpfs? Why tmpfs only, fro my perspective it should fix anything.
BTW, I recall there was another issue with unlinked files on tmpfs.
How about that one?

> 4) I need the last patch which would address case when name
>    of watchee is mangled via bindmount. And for this
>    we've at moment two patches
> 
> 	a) fsnotify: Use longest mount point for inotify watchee
> 	b) fsnotify: Guess the path to open if multiple mount namespace are present
> 
>    Both address same problem, but I aimed for b) mostly. Both are
>    under review. And I need to find out if there some better way
>    than guessing the path.
> 
> That said, namepsace wide watchees are still pain and under
> investigation but THIS particular patch is rather addressing
> mountnamespace issue, unrelated to fsnotify and should be
> merged, because fsnotify gonna rely on it.

OK

-- Pavel