From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754535AbcESLYV (ORCPT ); Thu, 19 May 2016 07:24:21 -0400 Received: from mail-db3on0104.outbound.protection.outlook.com ([157.55.234.104]:6300 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754432AbcESLYS (ORCPT ); Thu, 19 May 2016 07:24:18 -0400 Authentication-Results: virtuozzo.com; dkim=none (message not signed) header.d=none;virtuozzo.com; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCHv9 0/2] mremap vDSO for 32-bit To: , References: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> CC: , , , , , , <0x7f454c46@gmail.com> From: Dmitry Safonov Message-ID: Date: Thu, 19 May 2016 12:50:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: HE1PR01CA0001.eurprd01.prod.exchangelabs.com (10.163.2.139) To AM5PR0801MB1298.eurprd08.prod.outlook.com (10.167.216.149) X-MS-Office365-Filtering-Correlation-Id: ffe14ca8-f8a1-47bc-5d9e-08d37fcb2a12 X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1298;2:UT8cKiO9HndXRNYp5uZgbHraRkxz6qt/+wphheIEnQ8NI1XkM5QBvYnibskgxBgbYdUPxpcFOAkPodJRRzjL4g6w+sZq3/LC2qYklA8N8P7Keow7awZREtNK2IVBef4URG60mmcVI7IUoJ4T1+v6fQIsTKqYZmzB+7UuMbsjdWrGGlOZJbFMRPw1uFL1eNDg;3:wXTyy2lVEhGyW3k8e76tguLYeiE1PYQo1avDwKIaTYrr3alH8ZweuKtb8wFajo3JKZRE31kHYliCOErHZrNU4cS3imYiNtqx+ZpESB2A2/6koCaWWJSVIdsytpcIWCiC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1298; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1298;25:gc+qDIKmO56fe7l5DgTcisdsn8OU6CE8TtGILO8VSkzS2ijP4mQMSJ8WkuWllpGG3zZt9BMeLZ2FntNc7UQ4k52Seq/elRidkkmMDubFOCAVoXQkZZmqPKzI/AkkMHo1eBAuR3OEuroce10WsQFqJEbn0FcAqtfO56kL9TChhjFVsUjsVtwThqiOAYuPpTP4rgTy1ibKsVJmal0wVd3KCdlv4VLT2nsYu3MCAEGHGFaG1A6Eq/GlnVWDbbuDZi+yoY6X3/P5pEwJDEStt5iBp8bV5w8ne2uE4Qu5BlNOAo6UJKNxxeYNqeOIfwaIUr9ufY6UptLVy717rucW1pHOosXs+ogh6hI68FORr6ZML+11DxS4s8vNmpf80Iksn+eH8Vg0MKQh7hSY8ckrAq+/c9znJ91DsXof6+VhdU30OquNvB+/Vkit6qIBAc//cIg3FRA3KLtfL+x3WiFEG/AQteQPzZ2ws7XRcLinBJjBtfx0SnNydIBn6BwoqoQFBKC52JVvTjbRyyvgmlzh3QNjZ7+Jfm479y7OQjK2NlsGFWLm2TIAotOYuCE1capZWUbYtkHpKBEeoXUsdGr36jWrEtsYeujlrqk22SuEYBM0Vo25rfWm15CwBt6uC5MO5vVuZIfRgap/dO8n+amLHAXHZJHt0ykprg04kqWZuynF0RVwKRxnjqbrAVkfgFtEWuNYJNO6+XctXrE/yFRLDmxTWw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:AM5PR0801MB1298;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1298; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1298;4:LtXAmboOZo/VFt6/1FtG+ll8zfDgeTRrSQH2xPpxKLuwKlxx722eev5n6dsAVZbjq/mPInwVr/pqYmvjHCK52obj46TMR3TkYEj+3PX5GBQ4WEjvezkDh4y16Izotamt2KyzzkevzpECzUCWaHfucWAC2X/kb341Q+dxhU/Dy6tpDUoZoDQ+UKEPbuPlUs45wGAz8uxpz8HXd9d2jg18E9ucPHTR7HYpBnAfOobrn/79MshEp1O107tG52xTTIjTke/N0pZdnkNRX3i0n2TqY94/M1etWt2pU7lt0J58RnGF9Rm4eGsLoQqy+Aq2FmJfEcheKuBke1rtY7tHDSdX7K2+czZGF5KHHZ6yQ+spJ2v5PK8PE35rj4Q91PE12NaXh+EIL1XRFssknd4TIwbxxEZdaFPAxAk7nBACWI/vwb8= X-Forefront-PRVS: 094700CA91 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(377454003)(54534003)(24454002)(5008740100001)(5004730100002)(83506001)(4326007)(81166006)(92566002)(33646002)(76176999)(8676002)(65956001)(66066001)(31696002)(586003)(31686004)(86362001)(42186005)(50986999)(3846002)(6116002)(189998001)(54356999)(64126003)(19580395003)(230700001)(5001770100001)(2906002)(36756003)(2950100001)(50466002)(23746002)(77096005)(65826006);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1298;H:[10.30.26.154];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM5PR0801MB1298;23:FMhEBEdbPGVHIfZBVS2ByW52DIWsTOR+K2a?= =?Windows-1252?Q?LssaUVCBj1FPVbcvS3x8Bu29eyyfx2QAm5n6YiLgMM7TOwnRMX1C0Do3?= =?Windows-1252?Q?CKLbIEWgyYINdXbsVxhVQRpidhmr0/x12ykCQum4cdO1pDrpTzFXwHiT?= =?Windows-1252?Q?ZoTmG2Ac+qVYpNmNtLctUBHGgnUoJ7d7O1vIN44CURt/unq3iRGcyGwn?= =?Windows-1252?Q?hOGiAmQqqDTrKmC4NAZpgG6LE4wO+qcYe5MLJD9bmaBcuLkd34MIBRFQ?= =?Windows-1252?Q?d58fHEAX7StwCgmv58JKQ0CJyYgjNS+tYBSOPYrZJdPRxxrd/rD4El3+?= =?Windows-1252?Q?MdXDxfl4jeIsLenYaDkICJ+3s3lMd8y/iffRMtG/Q4J1CZ7YhnwlzPdM?= =?Windows-1252?Q?7bUHShz9D2h8xI1219EJSsSbBQpYpiYRu79fuzmlPJLaUXOvcw/KNjxp?= =?Windows-1252?Q?OBChsmjti5TqCnLvakDQMZP6bhHVwfyLMLN+oDZcZTpbaZMVk2O8SfcB?= =?Windows-1252?Q?svdaMBAzYUKpeYmKeH1tWHc11DlBe/OUO1Z9kXfCk0Thzp+Yi2r0+YOl?= =?Windows-1252?Q?vH8IqhSp8B7XY1XLsgFDU4IKCkb/hMsH1OhGoa3N+hLiwAKG/Yc7Skj6?= =?Windows-1252?Q?WrV7BUX3RzncrOQUtnWSHyw3LBWdt6PRo4OTEyGd0TEbi3jZXUGqOu6I?= =?Windows-1252?Q?7EMHDS322/Fz6FL1iWGAosKeePuEjRplP5YLtljlmFcNeU8KG7zfE++s?= =?Windows-1252?Q?4g3qW+S9N8wh4E6OC3GuqrNI0mqlZkYejvJk4b3VgU0c5WVnaC2HlQcv?= =?Windows-1252?Q?8V9rhSyp+ogd4IjVGeT6iE3tQa1NkKq9YWkToFWk1Zx8sYiAliczORd+?= =?Windows-1252?Q?Imh2v7qBiLtEwZT+QRIYNMx4/IS+qjSJevwlNvnOQ5bWCDMAZb9ctNor?= =?Windows-1252?Q?MBv1VQFAy5dvGvRxoI3Zt3b4CRE30DcmheC2fnlq6q/izVyBs6OPGmqT?= =?Windows-1252?Q?PnOScOIiEj/r02ZNIXDAezd+EGO17q4uR7HfkS7uyQGAjp5SF/emCNrm?= =?Windows-1252?Q?3AGqaf0AVgviNm0JEQ/SF47hHzR4aX8Hi/Q2R?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1298;5:GHanmAwdhUJ+k5p+4op0pHCHp1zhF3YvZ4wGZH0gY28oyoR1hQqAts/aI2fe1cWJrOHYy+pZDGwkZavwCpMq5ikkL5PJQ+JcHIoGIuwQH6qHbgRO3EfaLxMZyW3xtJpSDPsyrxPiXSchQyd/ir/fcg==;24:byNig0R+cR75D+S07b8xc+m6oDKz8G098ZdIKjbHoWFfO4t/nJTHbqg4W2uNU/g1S1pECGwIZVAEu0N5+Ppv5eVacnNAsSDqHuAyrCsTbN0=;7:mto79mMejkwIOiUcl+piFE5tTpCXLYtm25T38nuh5emLsrCWr2e3QHo2y8j+COWPjVguWJjahR7TuZpKQVDXAOgEj8ZDWpkKuNjiDDX9eILZ2sMZEwwNmoToDuBvMDyZy4UGybwRQG6B6ZAPTx/BDRIw0YhMjsK0I+RrMr3cIagkDqg1KYYB0HOP4ahTTv7R;20:fiLCSTC9HodDOoXex/4XWGmbo8kGW2TiaTF/Ji0gdZj636T8gIELadKTqP2/NwDJY0setZCCZ/6cO6mIGN4ZhGK4gh06pWJpvOBaqCF8XaCTJpRxOD9iofBboALGHaoJg9BFCdu/vJtkBOct/dLH678mQO/vOZ0eMyU90KP6rYQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2016 09:51:33.5462 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1298 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/17/2016 03:13 PM, Dmitry Safonov wrote: > The first patch adds support of mremapping 32-bit vDSO. > One could move vDSO vma before this patch, but fast syscalls > on moved vDSO hasn't been working. It's because of code that > relies on mm->context.vdso pointer. > So all this code is just fixup for that pointer on moving. > (Also adds preventing for splitting vDSO vma). > As Andy notted, 64-bit vDSO mremap also has worked only by a chance > before this patches. > The second patch adds a test for the new functionality. > > I need possibility to move vDSO in CRIU - on restore we need > to choose vma's position: > - if vDSO blob of restoring application is the same as the kernel has, > we need to move it on the same place; > - if it differs, we need to choose place that wasn't tooken by other > vma of restoring application and than add jump trampolines to it > from the place of vDSO in restoring application. > > CRIU code now relies on possibility on x86_64 to mremap vDSO. > Without this patch that may be broken in future. > And as I work on C/R of compatible 32-bit applications on x86_64, > I need mremap to work also for 32-bit vDSO. Which does not work, > because of context.vdso pointer mentioned above. > > Changes: > v9: Added cover-letter with changelog and reasons for patches > v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm; > run test for x86_64 too; > removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping > v7: Build fix > v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function > with ifdefs around > v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are > the same, also check not only in_ia32_syscall() but image == &vdso_image_32; > added test for mremapping vDSO > v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32 > v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap; > used is_ia32_task instead of ifdefs > v2: Added __maybe_unused for pt_regs in vdso_mremap Ping? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id 76CF56B0005 for ; Thu, 19 May 2016 05:51:38 -0400 (EDT) Received: by mail-io0-f198.google.com with SMTP id 190so158056873iow.2 for ; Thu, 19 May 2016 02:51:38 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0099.outbound.protection.outlook.com. [104.47.0.99]) by mx.google.com with ESMTPS id e1si1812196oex.95.2016.05.19.02.51.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 02:51:37 -0700 (PDT) Subject: Re: [PATCHv9 0/2] mremap vDSO for 32-bit References: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> From: Dmitry Safonov Message-ID: Date: Thu, 19 May 2016 12:50:20 +0300 MIME-Version: 1.0 In-Reply-To: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org, mingo@redhat.com Cc: luto@amacapital.net, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, 0x7f454c46@gmail.com On 05/17/2016 03:13 PM, Dmitry Safonov wrote: > The first patch adds support of mremapping 32-bit vDSO. > One could move vDSO vma before this patch, but fast syscalls > on moved vDSO hasn't been working. It's because of code that > relies on mm->context.vdso pointer. > So all this code is just fixup for that pointer on moving. > (Also adds preventing for splitting vDSO vma). > As Andy notted, 64-bit vDSO mremap also has worked only by a chance > before this patches. > The second patch adds a test for the new functionality. > > I need possibility to move vDSO in CRIU - on restore we need > to choose vma's position: > - if vDSO blob of restoring application is the same as the kernel has, > we need to move it on the same place; > - if it differs, we need to choose place that wasn't tooken by other > vma of restoring application and than add jump trampolines to it > from the place of vDSO in restoring application. > > CRIU code now relies on possibility on x86_64 to mremap vDSO. > Without this patch that may be broken in future. > And as I work on C/R of compatible 32-bit applications on x86_64, > I need mremap to work also for 32-bit vDSO. Which does not work, > because of context.vdso pointer mentioned above. > > Changes: > v9: Added cover-letter with changelog and reasons for patches > v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm; > run test for x86_64 too; > removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping > v7: Build fix > v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function > with ifdefs around > v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are > the same, also check not only in_ia32_syscall() but image == &vdso_image_32; > added test for mremapping vDSO > v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32 > v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap; > used is_ia32_task instead of ifdefs > v2: Added __maybe_unused for pt_regs in vdso_mremap Ping? -- 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