[Devel] [PATCH RH9] fs/namei: allow hardlinking between mounts with the same superblock

[Konstantin Khorenko]

On 12.11.2021 17:00, Pavel Tikhomirov wrote:
> 
> 
> On 12.11.2021 16:40, Pavel Tikhomirov wrote:
>>
>>
>> On 12.11.2021 15:34, Andrey Zhadchenko wrote:
>>> When we dump deleted files in criu, we are re-linking them back to fs, so
>>> we don't need to copy them. But if the mount where this file resides is
>>> overmounted we need to uncover it first. Uncovering it in original mount
>>> namespace is very difficult since we may need to unfreeze processes back
>>> if we failed somewhere later or even doing snapshot. So we copy mount
>>> namespace and uncover this mount there. Unfortunately we can't hardlink
>>> open fd to this uncovered mount since it is not the same mount where the
>>> file was.
>>> Technically there is no problem to create hardlink if superblock is
>>> the same for both mounts. Allow this for CAP_SYS_ADMIN and ve_pseudosper.
>>>
>>> https://jira.sw.ru/browse/PSBM-127834
>>
>> I do not see another way to solve problem with dumping an fd with
>> unlinked path but existing another hardlink, when fd is residing on
>> overmounted or detached mount.
> 
> Heh, I've found another way though =)
> 
> if we do name_to_handle_at on fd we can later reopen it by
> open_by_handle_at on other mount, so we can likely hardlink it on other
> mount from fd recieved by open_by_handle.
> 
> []# echo TEST > /tmp/test-file
> 
> []$ ln /tmp/test-file /tmp/test-hardlink
> 
> []$ ls -il /tmp/test-hardlink
> 
> 26821 -rw-rw-r--. 2 snorch snorch 0 ноя 12 16:48 /tmp/test-hardlink
> 
> []$ ls -il /tmp/test-file
> 
> 26821 -rw-rw-r--. 2 snorch snorch 0 ноя 12 16:48 /tmp/test-file
> 
> []$ ./name_to_handle_at /tmp/test-file
> 
> 90
> 
> 12 1    ea 3e 49 95 c5 68 00 00 00 00 00 00
> 
> []# mount --bind /tmp /tmp2
> 
> []# rm /tmp/test-file
> 
> []# ./open_by_handle_at /tmp2
> 
> 90
> 
> 12 1    ea 3e 49 95 c5 68 00 00 00 00 00 00
> 
> open_by_handle_at
> 
> fd=4
> 
> Read 5 bytes
> 
> []#
> 
> https://git.sw.ru/users/ptikhomirov/repos/helpers/browse/name_to_handle_at.c
> https://git.sw.ru/users/ptikhomirov/repos/helpers/browse/open_by_handle_at.c
> 
> So probably we can do link-remap files without this patch.

So, i'm dropping this patch, please let me know in case you decide we still need it.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

> 
>>
>> Reviewed-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
>>
>>> Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko at virtuozzo.com>
>>> ---
>>>    fs/namei.c | 8 +++++++-
>>>    1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/namei.c b/fs/namei.c
>>> index 38f52c1..6361f52 100644
>>> --- a/fs/namei.c
>>> +++ b/fs/namei.c
>>> @@ -39,6 +39,7 @@
>>>    #include <linux/bitops.h>
>>>    #include <linux/init_task.h>
>>>    #include <linux/uaccess.h>
>>> +#include <linux/ve.h>
>>>    #include "internal.h"
>>>    #include "mount.h"
>>> @@ -4370,7 +4371,12 @@ static int do_linkat(int olddfd, const char
>>> __user *oldname, int newdfd,
>>>        error = -EXDEV;
>>>        if (old_path.mnt != new_path.mnt)
>>> -        goto out_dput;
>>> +#ifdef CONFIG_VE
>>> +        if (!((old_path.mnt->mnt_sb == new_path.mnt->mnt_sb) &&
>>> +              (capable(CAP_SYS_ADMIN) ||
>>> get_exec_env()->is_pseudosuper)))
>>> +#endif
>>> +            goto out_dput;
>>> +
>>>        mnt_userns = mnt_user_ns(new_path.mnt);
>>>        error = may_linkat(mnt_userns, &old_path);
>>>        if (unlikely(error))
>>>
>>
>