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

Pavel Tikhomirov ptikhomirov at virtuozzo.com
Fri Nov 12 17:00:20 MSK 2021



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.

> 
> 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))
>>
> 

-- 
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.


More information about the Devel mailing list