From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754552AbaETRsK (ORCPT ); Tue, 20 May 2014 13:48:10 -0400 Received: from mail-la0-f49.google.com ([209.85.215.49]:54144 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbaETRsI (ORCPT ); Tue, 20 May 2014 13:48:08 -0400 Date: Tue, 20 May 2014 21:47:59 +0400 From: Cyrill Gorcunov To: Andy Lutomirski Cc: X86 ML , Andrew Morton , Sasha Levin , "linux-mm@kvack.org" , Dave Jones , LKML , Pavel Emelyanov , "H. Peter Anvin" Subject: Re: [PATCH 3/4] x86,mm: Improve _install_special_mapping and fix x86 vdso naming Message-ID: <20140520174759.GK2185@moon> References: <276b39b6b645fb11e345457b503f17b83c2c6fd0.1400538962.git.luto@amacapital.net> <20140520172134.GJ2185@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 20, 2014 at 10:24:49AM -0700, Andy Lutomirski wrote: > On Tue, May 20, 2014 at 10:21 AM, Cyrill Gorcunov wrote: > > On Mon, May 19, 2014 at 03:58:33PM -0700, Andy Lutomirski wrote: > >> Using arch_vma_name to give special mappings a name is awkward. x86 > >> currently implements it by comparing the start address of the vma to > >> the expected address of the vdso. This requires tracking the start > >> address of special mappings and is probably buggy if a special vma > >> is split or moved. > >> > >> Improve _install_special_mapping to just name the vma directly. Use > >> it to give the x86 vvar area a name, which should make CRIU's life > >> easier. > >> > >> As a side effect, the vvar area will show up in core dumps. This > >> could be considered weird and is fixable. Thoughts? > >> > >> Cc: Cyrill Gorcunov > >> Cc: Pavel Emelyanov > >> Signed-off-by: Andy Lutomirski > > > > Hi Andy, thanks a lot for this! I must confess I don't yet know how > > would we deal with compat tasks but this is 'must have' mark which > > allow us to detect vvar area! > > Out of curiosity, how does CRIU currently handle checkpointing a > restored task? In current kernels, the "[vdso]" name in maps goes > away after mremapping the vdso. We use not only [vdso] mark to detect vdso area but also page frame number of the living vdso. If mark is not present in procfs output we examinate executable areas and check if pfn == vdso_pfn, it's a slow path because there migh be a bunch of executable areas and touching every of it is not that fast thing, but we simply have no choise. The situation get worse when task was dumped on one kernel and then restored on another kernel where vdso content is different from one save in image -- is such case as I mentioned we need that named vdso proxy which redirect calls to vdso of the system where task is restoring. And when such "restored" task get checkpointed second time we don't dump new living vdso but save only old vdso proxy on disk (detecting it is a different story, in short we inject a unique mark into elf header). > > I suspect that you'll need kernel changes for compat tasks, since I > think that mremapping the vdso on any reasonably modern hardware in a > 32-bit task will cause sigreturn to blow up. This could be fixed by > making mremap magical, although adding a new prctl or arch_prctl to > reliably move the vdso might be a better bet. Well, as far as I understand compat code uses abs addressing for vvar data and if vvar data position doesn't change we're safe, but same time because vvar addresses are not abi I fear one day we indeed hit the problems and the only solution would be to use kernel's help. But again, Andy, I didn't think much about implementing compat mode in criu yet so i might be missing some details. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by kanga.kvack.org (Postfix) with ESMTP id E83E56B0036 for ; Tue, 20 May 2014 13:48:08 -0400 (EDT) Received: by mail-la0-f43.google.com with SMTP id mc6so695806lab.16 for ; Tue, 20 May 2014 10:48:08 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [2a00:1450:4010:c04::231]) by mx.google.com with ESMTPS id o7si17800070lao.96.2014.05.20.10.48.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 10:48:07 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so676178lbd.36 for ; Tue, 20 May 2014 10:48:06 -0700 (PDT) Date: Tue, 20 May 2014 21:47:59 +0400 From: Cyrill Gorcunov Subject: Re: [PATCH 3/4] x86,mm: Improve _install_special_mapping and fix x86 vdso naming Message-ID: <20140520174759.GK2185@moon> References: <276b39b6b645fb11e345457b503f17b83c2c6fd0.1400538962.git.luto@amacapital.net> <20140520172134.GJ2185@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: X86 ML , Andrew Morton , Sasha Levin , "linux-mm@kvack.org" , Dave Jones , LKML , Pavel Emelyanov , "H. Peter Anvin" On Tue, May 20, 2014 at 10:24:49AM -0700, Andy Lutomirski wrote: > On Tue, May 20, 2014 at 10:21 AM, Cyrill Gorcunov wrote: > > On Mon, May 19, 2014 at 03:58:33PM -0700, Andy Lutomirski wrote: > >> Using arch_vma_name to give special mappings a name is awkward. x86 > >> currently implements it by comparing the start address of the vma to > >> the expected address of the vdso. This requires tracking the start > >> address of special mappings and is probably buggy if a special vma > >> is split or moved. > >> > >> Improve _install_special_mapping to just name the vma directly. Use > >> it to give the x86 vvar area a name, which should make CRIU's life > >> easier. > >> > >> As a side effect, the vvar area will show up in core dumps. This > >> could be considered weird and is fixable. Thoughts? > >> > >> Cc: Cyrill Gorcunov > >> Cc: Pavel Emelyanov > >> Signed-off-by: Andy Lutomirski > > > > Hi Andy, thanks a lot for this! I must confess I don't yet know how > > would we deal with compat tasks but this is 'must have' mark which > > allow us to detect vvar area! > > Out of curiosity, how does CRIU currently handle checkpointing a > restored task? In current kernels, the "[vdso]" name in maps goes > away after mremapping the vdso. We use not only [vdso] mark to detect vdso area but also page frame number of the living vdso. If mark is not present in procfs output we examinate executable areas and check if pfn == vdso_pfn, it's a slow path because there migh be a bunch of executable areas and touching every of it is not that fast thing, but we simply have no choise. The situation get worse when task was dumped on one kernel and then restored on another kernel where vdso content is different from one save in image -- is such case as I mentioned we need that named vdso proxy which redirect calls to vdso of the system where task is restoring. And when such "restored" task get checkpointed second time we don't dump new living vdso but save only old vdso proxy on disk (detecting it is a different story, in short we inject a unique mark into elf header). > > I suspect that you'll need kernel changes for compat tasks, since I > think that mremapping the vdso on any reasonably modern hardware in a > 32-bit task will cause sigreturn to blow up. This could be fixed by > making mremap magical, although adding a new prctl or arch_prctl to > reliably move the vdso might be a better bet. Well, as far as I understand compat code uses abs addressing for vvar data and if vvar data position doesn't change we're safe, but same time because vvar addresses are not abi I fear one day we indeed hit the problems and the only solution would be to use kernel's help. But again, Andy, I didn't think much about implementing compat mode in criu yet so i might be missing some details. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org