parasite: don't use a process stack to unmap a parasite blob

Submitted by Andrei Vagin on Aug. 18, 2016, 6:37 a.m.

Details

Message ID 1471502256-19536-1-git-send-email-avagin@openvz.org
State Accepted
Series "parasite: don't use a process stack to unmap a parasite blob"
Commit 2784e81df8e235817cca0359b102e8c962e12f22
Headers show

Commit Message

Andrei Vagin Aug. 18, 2016, 6:37 a.m.
From: Andrei Vagin <avagin@virtuozzo.com>

Process private memory was dumped at this moment, but a memory
tracker isn't reseted, so we can't use a process memory here.

https://github.com/xemul/criu/issues/203

Cc: Eugene Batalov <eabatalov89@gmail.com>
Cc: Fyodor Bocharov <fbocharov@yandex.ru>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Fixes: 101e3ba49d08 ("mem: reset SOFT_DIRTY bits after dumping of all vmas in the process")
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
---
 criu/parasite-syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/criu/parasite-syscall.c b/criu/parasite-syscall.c
index 79d04a7..18923a5 100644
--- a/criu/parasite-syscall.c
+++ b/criu/parasite-syscall.c
@@ -1216,7 +1216,7 @@  int parasite_unmap(struct parasite_ctl *ctl, unsigned long addr)
 	pid_t pid = ctl->pid.real;
 	int ret = -1;
 
-	ret = parasite_run(pid, PTRACE_SYSCALL, addr, NULL, &regs, &ctl->orig);
+	ret = parasite_run(pid, PTRACE_SYSCALL, addr, ctl->rstack, &regs, &ctl->orig);
 	if (ret)
 		goto err;
 

Comments

Mike Rapoport Aug. 18, 2016, 7:31 a.m.
On Thu, Aug 18, 2016 at 9:37 AM, Andrei Vagin <avagin@openvz.org> wrote:
> From: Andrei Vagin <avagin@virtuozzo.com>
>
> Process private memory was dumped at this moment, but a memory
> tracker isn't reseted, so we can't use a process memory here.
>
> https://github.com/xemul/criu/issues/203
>
> Cc: Eugene Batalov <eabatalov89@gmail.com>
> Cc: Fyodor Bocharov <fbocharov@yandex.ru>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Fixes: 101e3ba49d08 ("mem: reset SOFT_DIRTY bits after dumping of all vmas in the process")
> Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
> ---
>  criu/parasite-syscall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/criu/parasite-syscall.c b/criu/parasite-syscall.c
> index 79d04a7..18923a5 100644
> --- a/criu/parasite-syscall.c
> +++ b/criu/parasite-syscall.c
> @@ -1216,7 +1216,7 @@ int parasite_unmap(struct parasite_ctl *ctl, unsigned long addr)
>         pid_t pid = ctl->pid.real;
>         int ret = -1;
>
> -       ret = parasite_run(pid, PTRACE_SYSCALL, addr, NULL, &regs, &ctl->orig);
> +       ret = parasite_run(pid, PTRACE_SYSCALL, addr, ctl->rstack, &regs, &ctl->orig);

Just curious, why parasite would use dumpee stack?
Wouldn't it make sense to always run with ctl->rstack?

>         if (ret)
>                 goto err;
>
> --
> 2.7.4
>
> _______________________________________________
> CRIU mailing list
> CRIU@openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
Andrei Vagin Aug. 18, 2016, 7:47 a.m.
On Thu, Aug 18, 2016 at 12:31 AM, Mike Rapoport <mike.rapoport@gmail.com> wrote:
> On Thu, Aug 18, 2016 at 9:37 AM, Andrei Vagin <avagin@openvz.org> wrote:
>> From: Andrei Vagin <avagin@virtuozzo.com>
>>
>> Process private memory was dumped at this moment, but a memory
>> tracker isn't reseted, so we can't use a process memory here.
>>
>> https://github.com/xemul/criu/issues/203
>>
>> Cc: Eugene Batalov <eabatalov89@gmail.com>
>> Cc: Fyodor Bocharov <fbocharov@yandex.ru>
>> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
>> Fixes: 101e3ba49d08 ("mem: reset SOFT_DIRTY bits after dumping of all vmas in the process")
>> Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
>> ---
>>  criu/parasite-syscall.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/criu/parasite-syscall.c b/criu/parasite-syscall.c
>> index 79d04a7..18923a5 100644
>> --- a/criu/parasite-syscall.c
>> +++ b/criu/parasite-syscall.c
>> @@ -1216,7 +1216,7 @@ int parasite_unmap(struct parasite_ctl *ctl, unsigned long addr)
>>         pid_t pid = ctl->pid.real;
>>         int ret = -1;
>>
>> -       ret = parasite_run(pid, PTRACE_SYSCALL, addr, NULL, &regs, &ctl->orig);
>> +       ret = parasite_run(pid, PTRACE_SYSCALL, addr, ctl->rstack, &regs, &ctl->orig);
>
> Just curious, why parasite would use dumpee stack?

parasite_run() is used to map a parasite blob with a parasite stack

> Wouldn't it make sense to always run with ctl->rstack?
>
>>         if (ret)
>>                 goto err;
>>
>> --
>> 2.7.4
>>
>> _______________________________________________
>> CRIU mailing list
>> CRIU@openvz.org
>> https://lists.openvz.org/mailman/listinfo/criu
>
>
>
> --
> Sincerely yours,
> Mike.
Pavel Emelianov Aug. 19, 2016, 10:42 a.m.
Applied

On 08/18/2016 09:37 AM, Andrei Vagin wrote:
> From: Andrei Vagin <avagin@virtuozzo.com>
> 
> Process private memory was dumped at this moment, but a memory
> tracker isn't reseted, so we can't use a process memory here.
> 
> https://github.com/xemul/criu/issues/203
> 
> Cc: Eugene Batalov <eabatalov89@gmail.com>
> Cc: Fyodor Bocharov <fbocharov@yandex.ru>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Fixes: 101e3ba49d08 ("mem: reset SOFT_DIRTY bits after dumping of all vmas in the process")
> Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
> ---
>  criu/parasite-syscall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/criu/parasite-syscall.c b/criu/parasite-syscall.c
> index 79d04a7..18923a5 100644
> --- a/criu/parasite-syscall.c
> +++ b/criu/parasite-syscall.c
> @@ -1216,7 +1216,7 @@ int parasite_unmap(struct parasite_ctl *ctl, unsigned long addr)
>  	pid_t pid = ctl->pid.real;
>  	int ret = -1;
>  
> -	ret = parasite_run(pid, PTRACE_SYSCALL, addr, NULL, &regs, &ctl->orig);
> +	ret = parasite_run(pid, PTRACE_SYSCALL, addr, ctl->rstack, &regs, &ctl->orig);
>  	if (ret)
>  		goto err;
>  
>