Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752616AbdG1TGn (ORCPT ); Fri, 28 Jul 2017 15:06:43 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33232 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752229AbdG1TGm (ORCPT ); Fri, 28 Jul 2017 15:06:42 -0400 MIME-Version: 1.0 In-Reply-To: <20170728164800.GD14170@arm.com> References: <20170726170737.21696-1-dsafonov@virtuozzo.com> <20170728164800.GD14170@arm.com> From: Dmitry Safonov <0x7f454c46@gmail.com> Date: Fri, 28 Jul 2017 22:06:20 +0300 Message-ID: Subject: Re: [PATCH] arm64/vdso: Support mremap() for vDSO To: Will Deacon Cc: Dmitry Safonov , open list , Catalin Marinas , Russell King , linux-arm-kernel@lists.infradead.org, Cyrill Gorcunov , Pavel Emelyanov , Christopher Covington Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2967 Lines: 80 2017-07-28 19:48 GMT+03:00 Will Deacon : > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> vDSO VMA address is saved in mm_context for the purpose of using >> restorer from vDSO page to return to userspace after signal handling. >> >> In Checkpoint Restore in Userspace (CRIU) project we place vDSO VMA >> on restore back to the place where it was on the dump. >> With the exception for x86 (where there is API to map vDSO with >> arch_prctl()), we move vDSO inherited from CRIU task to restoree >> position by mremap(). >> >> CRIU does support arm64 architecture, but kernel doesn't update >> context.vdso pointer after mremap(). Which results in translation >> fault after signal handling on restored application: >> https://github.com/xemul/criu/issues/288 >> >> Make vDSO code track the VMA address by supplying .mremap() fops >> the same way it's done for x86 and arm32 by: >> commit b059a453b1cf ("x86/vdso: Add mremap hook to vm_special_mapping") >> commit 280e87e98c09 ("ARM: 8683/1: ARM32: Support mremap() for sigpage/vDSO"). >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Russell King >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: Cyrill Gorcunov >> Cc: Pavel Emelyanov >> Cc: Christopher Covington >> Signed-off-by: Dmitry Safonov >> --- >> arch/arm64/kernel/vdso.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c >> index e8f759f764f2..2d419006ad43 100644 >> --- a/arch/arm64/kernel/vdso.c >> +++ b/arch/arm64/kernel/vdso.c >> @@ -110,12 +110,27 @@ int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp) >> } >> #endif /* CONFIG_COMPAT */ >> >> +static int vdso_mremap(const struct vm_special_mapping *sm, >> + struct vm_area_struct *new_vma) >> +{ >> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start; >> + unsigned long vdso_size = vdso_end - vdso_start; > > You might be able to use vdso_pages here, but it depends on my question > below. Yes, shifting with PAGE_SHIFT. Is it just a preference? > >> + >> + if (vdso_size != new_size) >> + return -EINVAL; >> + >> + current->mm->context.vdso = (void *)new_vma->vm_start; >> + >> + return 0; >> +} >> + >> static struct vm_special_mapping vdso_spec[2] __ro_after_init = { >> { >> .name = "[vvar]", >> }, >> { >> .name = "[vdso]", >> + .mremap = vdso_mremap, > > Does this mean we move the vdso text, but not the data page? How does that > work? Well, the kernel tracks only vdso pages - to find restorer addr after a signal. In userspace one needs to move vvar and vdso vma pair accordingly, with the same order and offset of course. -- Dmitry