From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932988AbcEQMab (ORCPT ); Tue, 17 May 2016 08:30:31 -0400 Received: from mail-db3on0116.outbound.protection.outlook.com ([157.55.234.116]:13024 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932965AbcEQMa1 (ORCPT ); Tue, 17 May 2016 08:30:27 -0400 Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=none action=none header.from=virtuozzo.com; From: Dmitry Safonov To: , CC: , , , , , , <0x7f454c46@gmail.com>, Dmitry Safonov Subject: [PATCHv9 0/2] mremap vDSO for 32-bit Date: Tue, 17 May 2016 15:13:50 +0300 Message-ID: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.8.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AM4PR01CA0020.eurprd01.prod.exchangelabs.com (10.164.74.158) To AM5PR0801MB1299.eurprd08.prod.outlook.com (10.167.216.150) X-MS-Office365-Filtering-Correlation-Id: e1cdc718-64d2-4bab-f9e5-08d37e4ce496 X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1299;2:joy8LJ5OcCSLuth/LNDk2RLs287m5J+YakWa03Ldza4ECc0Xc5MPH+vZ/opyNqRCKSrGVM+t0jnopWoXxNg5Ebbjpy+HGHnV349cV3WTBjQjAMrrcyWLmivmtZvHbJcnudg81UJL8AcJ5xJ9I+MAeYwRuwbxGatKjjL9dsr2rC12DwSByfRQlNBwwDcFm6Vb;3:eWM8Ln3LaapeHdd9Lt8CugGB0l80iLi5cw+gy2v+rsqM4DBb6LeDEfJEkLUS+XvjRszwqpK9V0m9ptaaBkz2/cJ4BEBtD0VrQPi6Z3HiJQQ2gIerLrhAqZaoBConuXfa;25:w5kYuyh18IVMDXWgZPOVuZUNLk2Sit8UDPQJtQd2WWE4Xuw1vB8mi92BENm0S59TeV7IH++V5dAoAqx1fpESryED37vBiiu9lnn1HYAfz8oGL2k0O9vqndgt2BSCbMcK00tQ2bpRyvHevpcdzNHWzx8aoltdpGvMuOXu/02DYrdA2C3K9hsyFXgGDZ7qbjyS8yFDqZkFc5c/Y8vwSsghWDKGHyugYqFaWORueutGKRq6e7QrztMBvgWi0C5rqepIQ+uF1SWvTtsvQzAs9lfj1dJqTWbmpygUzYcW+uVYAdTeQYeOkGx7Uh0XriBixwGYkRB85v6uPlGV5UhPh8bTtVMo6Pg7e+TKtmW9jGAut7QSLEUUe9ItywRXLr8HDVfp03n2lupK0JjhFabShOnAPuzoQTgsU91tadK6webCVTA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1299; 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)(3002001)(10201501046)(6041072)(6043046);SRVR:AM5PR0801MB1299;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1299; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1299;4:khgnsPX4Y0i6PxLuLpTz7PHmshHZKDzFhxr1rBil67d/wO6PSn8hQ+ivDAtwfGGgIXsFDkdRiN7QcZ/12ZMKDnYdw4Cj4ROBnh6cUX1eYtLQswzwJO5EkBTw0UhSpFYOhi7V7YDsim/YNVzz8+IagmZW88reIbu+QgjswkOhFuy8lH3u7ChTRDHPn9RVhSINyl7cSbuj3uAxXVHgKAMS6YWEWxPxwEURiFy1FAUIkz0vMB1upVg8uh/JsiNw76xxAGKZGupV+j7/Lowmp1aWYBdl5Ix/Mq+SwXn5tYDXds4xfUO2u/ZIqcnbstug/2u88Ar/kf/v+0+HRhFmMGHwGHX9UtyHF1S/MUS0k3LQB96tB1NvKAqx6vRNZmaJ+lA47r2eGgnNt2ySiT8DLtctkWgfiUHhy6gdaGbieZkjses= X-Forefront-PRVS: 0945B0CC72 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(54534003)(50226002)(53416004)(50466002)(92566002)(4001430100002)(47776003)(42186005)(66066001)(81166006)(229853001)(107886002)(33646002)(8676002)(48376002)(189998001)(5008740100001)(2906002)(86362001)(77096005)(4326007)(19580395003)(5004730100002)(36756003)(586003)(3846002)(6116002)(5003940100001)(5001770100001)(50986999);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1299;H:dsafonov.sw.ru;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1299;23:ZhP0VWAql5vJNbSGrd/wpquAvVMqIh6Lnmwla4WGbVwknDX9W5V0n2ZKoUiTb94nvN09zAWvlniKpygkNYDIG3lhtrMgHM3BKwf/WztUjoZYV3Floe1Vpr1rR2onOrxSHzuqhvjd+zqMqWsBTMCqFrJID21IgjRM4CaEBhCt+6T/Xm52W/Z5JMZZhKFjA6W1Bg2gvitB3ENyu397HlN2NzOzow3zGGc0Bq2L7MZLGGJw7rqMYv6n48DF4IKYA/wTiIqEUxfo/Ohvkp+NE01dm+MLlFycxgBUizKb5/TBBuYmdlT9L33C8KxmpbIOg50qkPmaQOX9dF1ae6VSOY/Unh/2HpIgfoTF1UNv2qOyOfgzMoAaym/BjF5Qb26gYiNZnCYNNIgYnJE34+on+6oXC+FIybImYsTiDAkVMMfAM87+KvML47vSoDICRktoQJlxTxK3oN/QaIMIBjVNrfr64lZg1XGaGyaPfDqXPJgrZJz+mCJ7Jb0f2l/7rcbPbvpk2mJesTouIseLoVvKXAXEUrJOLveP2waIyANiDO5lBr/g1FpxTW13krFTJtshD0DAPtsMmcY0VU0MWV8V6mfsbkELBXGN4lPr7TAgo47ZxImNkJMfeHdqUDB6KZ0Lyh1IllTBdkrpz17k4WwrSd1vxokpUn86HtCccBUaSnP/SvkWYi5gPLtprRh0VPQIT+qyffiS1awiqd4D/WZazl5U+UfYaq1xYgVAGTcoxSAvfi1QjB3SF7P2Fz5/51vJ8wZzOT5h5jxIySGAEVosFzqbAyhuxJUsEzpR0XxCFm7P/XvRmFJf0LjGbnMOItCwXhpHTrx3rMafrHc+cmHmqP8BJoe2oxgvNWd5V30CWZeHcsjlLcIu4A8HbaRYvKpkicTYk3C6gX/flqzeFFZVZzU5gA== X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1299;5:LOBlxGzU1jPAwcQCJ68B9Mpw4sCYOnQqHiBkX1ph0oD4FLFY1WjUq4ncy+7gYJn5sTZjVO2+FfIC0mJ1LuHpbXQAC08BCaO1aJSer1joIvaxnUkPlUFGyWe/PNqnAJpc/rmNEbd8TuXJDAsdPpRdxA==;24:CpTIMgiNaKgOOT1PsSS1LTZhQilRW1/LY80xOeEw4fAPnCH67YeYwZx4+x0e7g0barv/3es3EOJP0ONELx0VhuHHknPLCtJ4L2ftEjO6B+g=;7:oOIsUPK/G+ILiK5mxw4JBnnKMVuTEDoRiJ/85vf3f9kC+kQwYav6+EKK0bZPdpYmeUbysVcywkS1GV6nPdZ06z7e8lS9UiCNET7AsdYP9lbgWwP4aeKDHf14Aeyh6u34u3IMJS1zyYQaukogKBoWUnArxKiydrgRBxDH+IvbcZ3FP5N1pKCDQbHjB3cmS3om;20:sEbEbglXp4yk25hUybKxgtZSYgWxF1MohBeoqDz/cW3ZZhVl0HLCSYklKaqNT4DlBOC43FHBj4XA+iKtaXQJQzwBpZ3m2x/5GKYeAKaeuJEcV0bgH7dQ4GrnpA5hnxnK6hUT6s5gLlhPs8TzTfs6hFwM6/pMXz3VEUyu4MW4my8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 12:15:09.6772 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1299 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Dmitry Safonov (2): x86/vdso: add mremap hook to vm_special_mapping selftest/x86: add mremap vdso test arch/x86/entry/vdso/vma.c | 47 ++++++++++-- include/linux/mm_types.h | 3 + mm/mmap.c | 10 +++ tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_mremap_vdso.c | 99 ++++++++++++++++++++++++++ 5 files changed, 155 insertions(+), 6 deletions(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c -- 2.8.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id 52B596B0005 for ; Tue, 17 May 2016 08:15:14 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id t140so23332615oie.0 for ; Tue, 17 May 2016 05:15:14 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0117.outbound.protection.outlook.com. [104.47.0.117]) by mx.google.com with ESMTPS id dh8si1130744oec.66.2016.05.17.05.15.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 05:15:13 -0700 (PDT) From: Dmitry Safonov Subject: [PATCHv9 0/2] mremap vDSO for 32-bit Date: Tue, 17 May 2016 15:13:50 +0300 Message-ID: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain 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, Dmitry Safonov 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 Dmitry Safonov (2): x86/vdso: add mremap hook to vm_special_mapping selftest/x86: add mremap vdso test arch/x86/entry/vdso/vma.c | 47 ++++++++++-- include/linux/mm_types.h | 3 + mm/mmap.c | 10 +++ tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_mremap_vdso.c | 99 ++++++++++++++++++++++++++ 5 files changed, 155 insertions(+), 6 deletions(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c -- 2.8.0 -- 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