From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincenzo Frascino Subject: Re: [PATCH 1/4] arm64: compat: Alloc separate pages for vectors and sigpage Date: Tue, 2 Apr 2019 11:01:04 +0100 Message-ID: <6c43e9f9-3500-b828-3cf9-1917b9de256a@arm.com> References: <20190401112025.40807-1-vincenzo.frascino@arm.com> <20190401112025.40807-2-vincenzo.frascino@arm.com> <20190401142754.GF14874@arrakis.emea.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190401142754.GF14874@arrakis.emea.arm.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Catalin Marinas Cc: linux-arch@vger.kernel.org, Mark Rutland , Will Deacon , linux-arm-kernel@lists.infradead.org List-Id: linux-arch.vger.kernel.org On 01/04/2019 15:27, Catalin Marinas wrote: > On Mon, Apr 01, 2019 at 12:20:22PM +0100, Vincenzo Frascino wrote: >> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c >> index 2d419006ad43..9556ad2036ef 100644 >> --- a/arch/arm64/kernel/vdso.c >> +++ b/arch/arm64/kernel/vdso.c >> @@ -1,5 +1,7 @@ >> /* >> - * VDSO implementation for AArch64 and vector page setup for AArch32. >> + * VDSO implementation for AArch64 and for AArch32: >> + * AArch64: vDSO implementation contains pages setup and data page update. >> + * AArch32: vDSO implementation contains sigreturn and kuser pages setup. >> * >> * Copyright (C) 2012 ARM Limited >> * >> @@ -53,61 +55,117 @@ struct vdso_data *vdso_data = &vdso_data_store.data; >> /* >> * Create and map the vectors page for AArch32 tasks. >> */ >> -static struct page *vectors_page[1] __ro_after_init; >> +/* >> + * aarch32_vdso_pages: >> + * 0 - kuser helpers >> + * 1 - sigreturn code >> + */ >> +static struct page *aarch32_vdso_pages[2] __ro_after_init; > > More of a nitpick, the code may be easier to follow if we had two > separate variables. Does the array buy us anything? > Even though it does not make much difference right now, it simplifies the implementation of the compat vdso going forward. But I agree with you, we can always make the code more readable hence I will introduce some meaningful defines in v2 (instead of 0 and 1 indexes). >> +static const struct vm_special_mapping aarch32_vdso_spec[2] = { >> + { >> + /* Must be named [vectors] for compatibility with arm. */ >> + .name = "[vectors]", >> + .pages = &aarch32_vdso_pages[0], >> + }, >> + { >> + /* Must be named [sigpage] for compatibility with arm. */ >> + .name = "[sigpage]", >> + .pages = &aarch32_vdso_pages[1], >> + }, >> +}; > [...] >> -int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp) >> +static int aarch32_kuser_helpers_setup(struct mm_struct *mm) >> { >> - struct mm_struct *mm = current->mm; >> - unsigned long addr = AARCH32_VECTORS_BASE; >> - static const struct vm_special_mapping spec = { >> - .name = "[vectors]", >> - .pages = vectors_page, >> + void *ret; >> + >> + /* The kuser helpers must be mapped at the ABI-defined high address */ >> + ret = _install_special_mapping(mm, AARCH32_KUSER_BASE, PAGE_SIZE, >> + VM_READ | VM_EXEC | >> + VM_MAYREAD | VM_MAYEXEC, >> + &aarch32_vdso_spec[0]); >> + >> + return PTR_ERR_OR_ZERO(ret); >> +} >> >> - }; >> +static int aarch32_sigreturn_setup(struct mm_struct *mm) >> +{ >> + unsigned long addr; >> void *ret; >> >> - if (down_write_killable(&mm->mmap_sem)) >> - return -EINTR; >> - current->mm->context.vdso = (void *)addr; >> + addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0); >> + if (IS_ERR_VALUE(addr)) { >> + ret = ERR_PTR(addr); >> + goto out; >> + } >> >> - /* Map vectors page at the high address. */ >> ret = _install_special_mapping(mm, addr, PAGE_SIZE, >> - VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYEXEC, >> - &spec); >> + VM_READ | VM_EXEC | VM_MAYREAD | >> + VM_MAYWRITE | VM_MAYEXEC, >> + &aarch32_vdso_spec[1]); > > Any reason for setting VM_MAYWRITE here? > VM_MAYWRITE is required to allow gdb to Copy-on-Write and set breakpoints. -- Regards, Vincenzo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:47644 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726468AbfDBKBI (ORCPT ); Tue, 2 Apr 2019 06:01:08 -0400 Subject: Re: [PATCH 1/4] arm64: compat: Alloc separate pages for vectors and sigpage References: <20190401112025.40807-1-vincenzo.frascino@arm.com> <20190401112025.40807-2-vincenzo.frascino@arm.com> <20190401142754.GF14874@arrakis.emea.arm.com> From: Vincenzo Frascino Message-ID: <6c43e9f9-3500-b828-3cf9-1917b9de256a@arm.com> Date: Tue, 2 Apr 2019 11:01:04 +0100 MIME-Version: 1.0 In-Reply-To: <20190401142754.GF14874@arrakis.emea.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Catalin Marinas Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon , Mark Rutland Message-ID: <20190402100104.xkD-C1i4xRGz1-PfrTucZ-fOsrnLvgxBiYDpSEDM4ic@z> On 01/04/2019 15:27, Catalin Marinas wrote: > On Mon, Apr 01, 2019 at 12:20:22PM +0100, Vincenzo Frascino wrote: >> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c >> index 2d419006ad43..9556ad2036ef 100644 >> --- a/arch/arm64/kernel/vdso.c >> +++ b/arch/arm64/kernel/vdso.c >> @@ -1,5 +1,7 @@ >> /* >> - * VDSO implementation for AArch64 and vector page setup for AArch32. >> + * VDSO implementation for AArch64 and for AArch32: >> + * AArch64: vDSO implementation contains pages setup and data page update. >> + * AArch32: vDSO implementation contains sigreturn and kuser pages setup. >> * >> * Copyright (C) 2012 ARM Limited >> * >> @@ -53,61 +55,117 @@ struct vdso_data *vdso_data = &vdso_data_store.data; >> /* >> * Create and map the vectors page for AArch32 tasks. >> */ >> -static struct page *vectors_page[1] __ro_after_init; >> +/* >> + * aarch32_vdso_pages: >> + * 0 - kuser helpers >> + * 1 - sigreturn code >> + */ >> +static struct page *aarch32_vdso_pages[2] __ro_after_init; > > More of a nitpick, the code may be easier to follow if we had two > separate variables. Does the array buy us anything? > Even though it does not make much difference right now, it simplifies the implementation of the compat vdso going forward. But I agree with you, we can always make the code more readable hence I will introduce some meaningful defines in v2 (instead of 0 and 1 indexes). >> +static const struct vm_special_mapping aarch32_vdso_spec[2] = { >> + { >> + /* Must be named [vectors] for compatibility with arm. */ >> + .name = "[vectors]", >> + .pages = &aarch32_vdso_pages[0], >> + }, >> + { >> + /* Must be named [sigpage] for compatibility with arm. */ >> + .name = "[sigpage]", >> + .pages = &aarch32_vdso_pages[1], >> + }, >> +}; > [...] >> -int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp) >> +static int aarch32_kuser_helpers_setup(struct mm_struct *mm) >> { >> - struct mm_struct *mm = current->mm; >> - unsigned long addr = AARCH32_VECTORS_BASE; >> - static const struct vm_special_mapping spec = { >> - .name = "[vectors]", >> - .pages = vectors_page, >> + void *ret; >> + >> + /* The kuser helpers must be mapped at the ABI-defined high address */ >> + ret = _install_special_mapping(mm, AARCH32_KUSER_BASE, PAGE_SIZE, >> + VM_READ | VM_EXEC | >> + VM_MAYREAD | VM_MAYEXEC, >> + &aarch32_vdso_spec[0]); >> + >> + return PTR_ERR_OR_ZERO(ret); >> +} >> >> - }; >> +static int aarch32_sigreturn_setup(struct mm_struct *mm) >> +{ >> + unsigned long addr; >> void *ret; >> >> - if (down_write_killable(&mm->mmap_sem)) >> - return -EINTR; >> - current->mm->context.vdso = (void *)addr; >> + addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0); >> + if (IS_ERR_VALUE(addr)) { >> + ret = ERR_PTR(addr); >> + goto out; >> + } >> >> - /* Map vectors page at the high address. */ >> ret = _install_special_mapping(mm, addr, PAGE_SIZE, >> - VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYEXEC, >> - &spec); >> + VM_READ | VM_EXEC | VM_MAYREAD | >> + VM_MAYWRITE | VM_MAYEXEC, >> + &aarch32_vdso_spec[1]); > > Any reason for setting VM_MAYWRITE here? > VM_MAYWRITE is required to allow gdb to Copy-on-Write and set breakpoints. -- Regards, Vincenzo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC4C2C4360F for ; Tue, 2 Apr 2019 10:01:20 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AFB1E20857 for ; Tue, 2 Apr 2019 10:01:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eo/KtzXx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFB1E20857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4lodrZzO+3fSR9rCnTmlIxt8W68OMqO6dN+6vXEsMa4=; b=eo/KtzXxCyDlE6 ilTKjmkdJ6ejQ2hhMSdBBRPWwomSfN2gdAKcaSDXLMfWhf41inJSiP7IPdX42SgNQ6TxdJ1LrjvP/ QgpDJmFfVqKJvbXEg5G2+FwIGkTb38vPh4JrtyPYxfxxGNMUyvdjgZtybEfG11sT4zHFrS72T9ryq HTW2o9pgWab/u3r6r+SBAUnfQKPd1TyN3Vy/kWJeepL+58Ch7JFLSleAInYoslpibkmj83iVLsSBv wo/NRCj/d8qhL2o82mU/fo8suqDSA/+u4Mjrlt3txWF9MZb7ImXzd7DLfNgdDhUX16N/T64ORU6lC DFFDJ3iq9w/y/BzFyneQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBGEC-0005EG-UV; Tue, 02 Apr 2019 10:01:12 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBGE9-0005Dq-6k for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 10:01:10 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4F25515AD; Tue, 2 Apr 2019 03:01:07 -0700 (PDT) Received: from [10.1.196.72] (e119884-lin.cambridge.arm.com [10.1.196.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5EFDE3F59C; Tue, 2 Apr 2019 03:01:06 -0700 (PDT) Subject: Re: [PATCH 1/4] arm64: compat: Alloc separate pages for vectors and sigpage To: Catalin Marinas References: <20190401112025.40807-1-vincenzo.frascino@arm.com> <20190401112025.40807-2-vincenzo.frascino@arm.com> <20190401142754.GF14874@arrakis.emea.arm.com> From: Vincenzo Frascino Message-ID: <6c43e9f9-3500-b828-3cf9-1917b9de256a@arm.com> Date: Tue, 2 Apr 2019 11:01:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190401142754.GF14874@arrakis.emea.arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_030109_259247_D145B7EC X-CRM114-Status: GOOD ( 20.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Mark Rutland , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 01/04/2019 15:27, Catalin Marinas wrote: > On Mon, Apr 01, 2019 at 12:20:22PM +0100, Vincenzo Frascino wrote: >> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c >> index 2d419006ad43..9556ad2036ef 100644 >> --- a/arch/arm64/kernel/vdso.c >> +++ b/arch/arm64/kernel/vdso.c >> @@ -1,5 +1,7 @@ >> /* >> - * VDSO implementation for AArch64 and vector page setup for AArch32. >> + * VDSO implementation for AArch64 and for AArch32: >> + * AArch64: vDSO implementation contains pages setup and data page update. >> + * AArch32: vDSO implementation contains sigreturn and kuser pages setup. >> * >> * Copyright (C) 2012 ARM Limited >> * >> @@ -53,61 +55,117 @@ struct vdso_data *vdso_data = &vdso_data_store.data; >> /* >> * Create and map the vectors page for AArch32 tasks. >> */ >> -static struct page *vectors_page[1] __ro_after_init; >> +/* >> + * aarch32_vdso_pages: >> + * 0 - kuser helpers >> + * 1 - sigreturn code >> + */ >> +static struct page *aarch32_vdso_pages[2] __ro_after_init; > > More of a nitpick, the code may be easier to follow if we had two > separate variables. Does the array buy us anything? > Even though it does not make much difference right now, it simplifies the implementation of the compat vdso going forward. But I agree with you, we can always make the code more readable hence I will introduce some meaningful defines in v2 (instead of 0 and 1 indexes). >> +static const struct vm_special_mapping aarch32_vdso_spec[2] = { >> + { >> + /* Must be named [vectors] for compatibility with arm. */ >> + .name = "[vectors]", >> + .pages = &aarch32_vdso_pages[0], >> + }, >> + { >> + /* Must be named [sigpage] for compatibility with arm. */ >> + .name = "[sigpage]", >> + .pages = &aarch32_vdso_pages[1], >> + }, >> +}; > [...] >> -int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp) >> +static int aarch32_kuser_helpers_setup(struct mm_struct *mm) >> { >> - struct mm_struct *mm = current->mm; >> - unsigned long addr = AARCH32_VECTORS_BASE; >> - static const struct vm_special_mapping spec = { >> - .name = "[vectors]", >> - .pages = vectors_page, >> + void *ret; >> + >> + /* The kuser helpers must be mapped at the ABI-defined high address */ >> + ret = _install_special_mapping(mm, AARCH32_KUSER_BASE, PAGE_SIZE, >> + VM_READ | VM_EXEC | >> + VM_MAYREAD | VM_MAYEXEC, >> + &aarch32_vdso_spec[0]); >> + >> + return PTR_ERR_OR_ZERO(ret); >> +} >> >> - }; >> +static int aarch32_sigreturn_setup(struct mm_struct *mm) >> +{ >> + unsigned long addr; >> void *ret; >> >> - if (down_write_killable(&mm->mmap_sem)) >> - return -EINTR; >> - current->mm->context.vdso = (void *)addr; >> + addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0); >> + if (IS_ERR_VALUE(addr)) { >> + ret = ERR_PTR(addr); >> + goto out; >> + } >> >> - /* Map vectors page at the high address. */ >> ret = _install_special_mapping(mm, addr, PAGE_SIZE, >> - VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYEXEC, >> - &spec); >> + VM_READ | VM_EXEC | VM_MAYREAD | >> + VM_MAYWRITE | VM_MAYEXEC, >> + &aarch32_vdso_spec[1]); > > Any reason for setting VM_MAYWRITE here? > VM_MAYWRITE is required to allow gdb to Copy-on-Write and set breakpoints. -- Regards, Vincenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel